Optimierung eines Media Asset Management Systems

Transkript

1 Optimierung eines Media Asset Management Systems Patricia Kalina M A S T E R A R B E I T eingereicht am Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg im September 2008

2 Copyright 2008 Patricia Kalina Alle Rechte vorbehalten ii

3 Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Hagenberg, am 24. September 2008 Patricia Kalina iii

4 Danksagung Ganz besonderer Dank gilt meiner Familie, die mir das Studium ermöglicht und mich stets nach ihren Möglichkeiten unterstützt hat. Insbesondere danke ich meiner Mutter, Ingeborg Kalina, für die kulinarische Betreuung in der Endphase der Diplomarbeit. Mein Dank gilt des Weiteren meinem Betreuer DI Rimbert Rudisch für seine Bemühungen und seine Geduld. Zusätzlich bin ich ihm dankbar, dass er immer den Glauben an mich und meine Diplomarbeit bewahrt hat. Ferner möchte ich mich bei meinen Fotomodellen bedanken: Christine Nunnenmacher, Mag. Sabine Strasser, DI(FH) Bernhard Bornatowicz, Ing. Manfred Brosenbauer und Mag. Albert Wolfgang. Ebenso geduldig wie die Fotomodelle waren auch meine Interviewpartner: Sonja Weghuber, Bsc., Ingrid Platz, Bsc., Günter Vorauer, Msc., Rene Swoboda, Msc., DI(FH) Dieter Nunnenmacher, Veronika Krauskopf sowie mein Vater, Herbert Kalina. Ihnen bin ich besonders für die ehrlichen und konstruktiven Angaben während der Befragungen zu der Benutzeroberfläche dankbar. Für das Korrekturlesen meiner Diplomarbeit möchte ich mich insbesondere bei DI(FH) Dieter Nunnenmacher bedanken. Zuletzt möchte ich Mag. Almuth Dietrich meinen Dank für ihre Unterstützung und ihre aufmunternden Worte aussprechen. iv

5 Kurzfassung Über den Erfolg eines Media Asset Management Systems entscheiden verschiedene Faktoren. Zum einen ist eine leistungsfähige und funktionsstarke Serverimplementierung erforderlich. Zum andern soll die Benutzeroberfläche die Bedürfnisse und die Erwartungen des späteren Benutzers erfüllen. Werden diese beiden Komponenten bei der Realisierung eines Media Asset Management Systems beachtet, kann es sich auf diese Weise von anderen Systemen abgrenzen. Die Konkurrenzfähigkeit des Systems wird so gewährleistet. Basierend auf der Analyse bestehender Projekte wurde eine serverseitige Implementierung unter Verwendung alternativer Technologien vorgenommen. Mit Hilfe von Zeitmessungen wurde eruiert, welche Konfiguration sich für diesen Anwendungsfall am besten eignet. Ferner wurde ein Benutzeroberflächenkonzept unter Berücksichtigung der gültigen Gestaltungsregeln entworfen. Unter Einbeziehung möglicher Endbenutzer wurde das Konzept geprüft und weiterentwickelt. Das Ergebnis ist die Empfehlung der geeigneten Technologien für die Umsetzung eines Media Asset Management Systems. Außerdem kann das erstellte Benutzeroberflächenkonzept als Ausgangsbasis für die Implementierung einer Benutzerapplikation zur Hand genommen werden. Durch die Umsetzung dieser Maßnahmen ist die Konkurrenzfähigkeit dieses Produkts gewahrt. v

6 Abstract For the success of a media asset management system different factors are essential. On the one hand, a powerful and functional server-side implementation is required. On the other hand, the user interface should respect the potential user s needs and expectations. The system is competitive, when those two factors are well realised. Before the implementation existing projects were analysed. Using the knowledge of the analysis the server-side was implemented with alternative technologies. The most suitable configuration for this product was identified through time measurements. Furthermore, a new concept for the user interface was created with respect to the current design rules. The user s needs and expectations were considered during this development process. As a result the most convenient technologies for the implementation of a media asset management are recommended. Moreover, a usable user application can be developed on the base of the given user interface concept. Because of the taken steps the competitiveness of this product is preserved. vi

7 Inhaltsverzeichnis Erklärung Kurzfassung Abstract iii v vi 1 Einleitung Motivation Ziele Übersicht Allgemeines Server Benutzeroberfläche Media Asset Management System Begriffserklärung Begriffsabgrenzung Content im Media Asset Management System 7 4 TEAPOT The Extendable Asset Persistent Object Store Geschichte Produktbeschreibung Stand der Technik (Server) 11 6 Technologien Spring Framework Objektrelationale Datenbankabbildungswerkzeuge Hibernate ibatis Datenbankmanagementsysteme MySQL PostgreSQL vii

8 Inhaltsverzeichnis viii 7 Anforderungen Media Assets Strukturen Die Suche als Mittelpunkt des MAMS Anwendungsfälle Akteure Anwendungsfälle Umsetzung Allgemeine Systemarchitektur Datenmodell Architektur von TEAPOT Core Allgemein Business Objects Data Access Objects Business Methods Evaluierung Allgemeines Einfache Suche Suche nach einem Schlagwort Suche nach einer Kategorie Suche nach einer Mediengruppe Interpretation der Ergebnisse der Zeitmessungen Stand der Technik (Benutzeroberfläche) Plädoyer für ein besseres Design Benutzerfreundlichkeit Begriffserklärung Heuristiken Ästhetisches und minimalistisches Design (Simple and Natural Dialogue) Kongruenz von System und realer Welt (Speak the Users Language) Reduzierung der Gedächtnisleistung (Minimize User Memory Load) Konsistenz und Standardkonformität (Consistency) Transparenz des Systemzustandes (Feedback) Handlungskontrolle und -spielraum des Anwenders (Clearly Marked Exits) Flexibilität und Effizienz der Anwendung (Shortcuts) Unterstützung bei der Entdeckung, Interpretation und Behebung von Fehlern (Good Error Messages) Fehlervermeidung (Prevent Errors) Hilfe und Dokumentation (Help and Documentation)

9 Inhaltsverzeichnis ix 13 Benutzer Kennen des Benutzers Benutzerwissen und Benutzergruppen Benutzerwissen Benutzergruppen Personas Allgemeines Personas für TEAPOT Szenarien Allgemeines Szenarien für TEAPOT Anforderungen an TEAPOT aus Anwendersicht Überlegungen zur Benutzeroberfläche Vergleich zwischen Web- und Desktopapplikation Entscheidung für eine Webapplikation Vorgehensweise Entwicklung der Benutzeroberfläche Befragung zur Benutzeroberfläche Die Benutzeroberfläche im Allgemeinen Struktur Seitenaufbau Konzept Registrierung und Anmeldung Kopfbereich Menü Menüführung Markierung einer aktiven Seite Piktogrammmenü Startseite Assets Erweiterte Suche Leuchtkasten Detailansicht Einspielen von Media Assets Verwaltung von Strukturen Administration Evaluierung der Benutzeroberfläche Zusammenfassung Ergebnis Problembereiche Ausblick

10 Inhaltsverzeichnis x A Inhalt der DVD 113 A.1 Benutzeroberfläche A.2 Diplomarbeit A.2.1 Abbildungen A.2.2 Internetquellen A.3 Server Literaturverzeichnis 115

11 Kapitel 1 Einleitung In der Einleitung werden die Motivation und die Ziele dieser Diplomarbeit erläutert. Ferner wird ein Überblick über die drei großen Teile dieser Diplomarbeit gegeben. 1.1 Motivation Gilt heute eben noch die Technologie A als das Maß der Dinge, kann morgen bereits die Technologie B das Beste sein. Die Informationstechnologie ist eine schnelllebige Branche, die stets eine Weiterentwicklung erlebt. Nach dem Projektabschluss hat das Media Asset Management System TEAPOT 1 (The Extendable Asset Persistent Object Store) aufgehört sich weiterzuentwickeln und ist in einer Zeit von stetigen Veränderungen stehen geblieben. Da Media Asset Management jedoch nach wie vor ein Markt bestimmendes Thema ist, soll das Projekt TEAPOT weiter betreut und aktualisiert werden. Es fiel daher der Entschluss ein Reengineering von TEAPOT durchzuführen. Zum einen betrifft dies die serverseitige Implementierung des Systems, das Herzstück TEAPOT Core. Zum anderen ist davon die Benutzeroberfläche betroffen. Durch diesen Neustart soll sich die Zukunft für TEAPOT besser gestalten. Ein erneuter Stillstand soll auf diese Weise vermieden werden. 1.2 Ziele Das erste Ziel dieser Arbeit ist die Neuspezifikation der Anforderungen anhand des bestehenden Projekts TEAPOT. Basierend auf dieser Spezifikation wird das Datenmodell sowie die Architektur für die serverseitige Implementierung überarbeitet. Für TEAPOT Core werden aktuelle Technologien eingesetzt, die zukünftig eine einfachere Wartung und Weiterentwicklung ermöglichen. Das zweite Ziel ist die Ermittlung der am besten geeigneten Technologien für die Entwicklung von TEAPOT Core. Dazu wird die serverseitige Implementierung mit zwei verschiedenen Datenbankmanagementsystemen und zwei verschiedenen objektrelationalen Datenbankabbildungswerkzeuge umgesetzt. Für die unterschiedlichen Kombinationen werden während einiger Tests Zeitmessungen durchgeführt, um so die am besten geeignete Kombination zu eruieren

12 1. Einleitung 2 Das dritte Ziel ist die Entwicklung eines Benutzeroberflächenkonzepts für TEAPOT. Für die Neugestaltung der Benutzeroberfläche wird in Form einer Studie der Grundstein gelegt. Dabei werden anhand eines Entwurfs die Erwartungen und die Bedürfnisse der Benutzer überprüft und erfasst. Die so gewonnen Erkenntnisse sind für die Weiterentwicklung des Benutzeroberflächenkonzepts essenziell, da die Benutzerfreundlichkeit eines Programms nur unter Berücksichtigung des Benutzers erhöht werden kann. Das vierte Ziel ist Verbesserung der Qualitätssicherung. Durch die Berücksichtigung von Programmierrichtlinien sowie die Einführung von Unit-Tests soll der zeitliche Aufwand für die Wartung und Weiterentwicklung von TEAPOT erheblich reduziert werden. Ein weiterer Weg zur Qualitätssicherung ist eine ausführliche Dokumentation des Projekts. Auf diese Weise soll anderen Entwicklern leichter fallen, sich in das Projekt TEAPOT einzuarbeiten. 1.3 Übersicht Dieser Abschnitt gibt dem Leser einen Überblick über die Inhalte dieser Diplomarbeit Allgemeines Kapitel 1 erläutert zunächst den Begriff Media Asset Management. Ferner werden ähnliche Begriffe abgegrenzt um Missverständnisse zu vermeiden. Kapitel 2 beschäftigt sich mit dem Inhalt eines Media Asset Management Systems. Dieser wird in die gespeicherten Dateien und deren Beschreibung durch Metadaten unterteilt. Kapitel 3 stellt das Media Asset Management System TEAPOT vor. Zunächst wird die bisherige Entwicklung von TEAPOT betrachtet. Anschließend wird der Leistungsumfang von TEAPOT beschrieben Server Kapitel 4 geht auf den Stand der Technik ein, wobei konkurrenzfähige Systeme vorgestellt werden. Im Zuge dessen wird auch die Implementierung eines eigenständigen Systems gerechtfertigt. Kapitel 5 beschreibt die Technologien, die der Implementierung von TEAPOT Core zugrunde liegen. Zu diesen Technologien zählt unter anderem das Spring Framework. Außerdem werden die beiden objektrelationalen Datenbankabbildungswerkzeuge Hibernate und ibatis vorgestellt. Ebenso werden die Datenbankmanagementsysteme MySQL und PostgreSQL beschrieben. Kapitel 6 definiert die Anforderungen an TEAPOT Core. Es wird zunächst erklärt, welche Daten in dem System gespeichert werden. Anschließend wird auf die Suche als zentrales Element eines Media Asset Management System eingegangen. In den Anwendungsfällen ist letztlich der geforderte Funktionsumfang festgelegt. Kapitel 7 widmet sich dem Konzept und der Implementierung von TEAPOT Core. Zunächst wird die allgemeine Systemarchitektur beschrieben um einen Überblick zu schaffen. Anschließend werden das Datenmodell sowie die elementaren Schichten von TEAPOT Core detailliert beschrieben. Kapitel 8 evaluiert die verschiedenen Technologien anhand von Zeitmessungen, die während der Tests aufgezeichnet wurden. Dabei ist die Suche der Mittelpunkt der Tests, da sie

13 1. Einleitung 3 einen wesentlichen Teil des Media Asset Management Systems repräsentiert. Als Ergebnis der Evaluierung wird die am besten geeignete Kombination von Technologien empfohlen Benutzeroberfläche Kapitel 9 betrachtet den Stand der Technik. Es werden Benutzeroberflächen bestehender Media Asset Management Systeme analysiert und beschrieben. Dabei werden die betrachteten Benutzeroberflächen in verschiedene Kategorien eingeteilt: Verwaltungssysteme, virtuelle Gemeinschaften und Verkaufsplattformen. Kapitel 10 macht auf das Problem aufmerksam, dass die Benutzeroberfläche im Entwicklungsprozess zumeist kaum berücksichtigt wird. Es gibt jedoch viele Gründe, warum es sich lohnt mehr Zeit in die Gestaltung der Benutzeroberfläche zu investieren. Kapitel 11 erklärt den vielschichtigen Begriff der Benutzerfreundlichkeit. Außerdem werden die wichtigsten Heuristiken der Benutzerfreundlichkeit nach Jakob Nielsen vorgestellt. Kapitel 12 widmet sich den vielseitigen Aspekten des Benutzers. Zunächst wird die zentrale Rolle des Benutzers in der Programmentwicklung erläutert. Anschließend werden die drei wesentlichen Benutzergruppen unterschieden. In den spezifischeren Unterkapiteln Personas und Szenarien werden die Zielgruppe für TEAPOT sowie deren Bedürfnisse hinsichtlich des Programms definiert. Zuletzt werden die Anforderungen der Benutzerseite zusammengefasst. Kapitel 13 erläutert die Unterschiede zwischen Web- und Desktopapplikationen. Danach wird die Entscheidung für eine Webapplikation begründet. Abschließend wird die Vorgehensweise zur Entwicklung der Benutzeroberfläche erklärt. Kapitel 14 beschreibt zu Beginn die Befragung als subjektive Beurteilungsgrundlage. Im Anschluss daran beschäftigt sich ein Unterkapitel mit dem allgemeinen Aspekt der Benutzeroberfläche. Danach wird die Benutzeroberfläche Seite für Seite beschrieben und analysiert. In die Analyse fließen bereits die Ergebnisse der Befragung über die Benutzeroberfläche ein. Kapitel 15 evaluiert das Benutzeroberflächenkonzept anhand eines Kriterienkatalogs objektiv. Die Ergebnisse der Evaluierung werden interpretiert und diskutiert.

14 Kapitel 2 Media Asset Management System In diesem Kapitel wird zunächst der Begriff Media Asset Management System erläutert. Ferner werden ähnliche Begriffe abgegrenzt um Missverständnisse zu vermeiden. 2.1 Begriffserklärung Für den Begriff Media Asset Management System werden häufig die folgenden Bezeichnungen synonym verwendet: Digital Asset Management System (DAMS), Media Warehouse System, Digital Media Management System (DMMS) und Digital Media Asset Management System (DMAMS). Der Ausdruck System, der Bestandteil der oben angeführten Bezeichnungen ist, umschreibt dabei eine konkretes Programm, das der Verwaltung von Medieninhalten dient. Der Einfachheit halber wird in dieser Diplomschrift ausschließlich der Ausdruck Media Asset Management System (MAMS) bzw. Media Asset Management (MAM) fallen. Christof Zahneissen, Geschäftsführer der Dubidot GmbH (Anbieter einer unternehmensweiten Media Asset Management Lösung), erklärt den Begriff Media Asset Management in einem Interview auf diese Weise [16]: MAM erlaubt das qualitätsgesicherte, rechtbasierte Management von unterschiedlichsten Medien (Bilder, Videos, Audios, Texten, Animationen etc.) an einem zentralen Ort. Die medienneutrale Bereitstellung der Medien [...] bildet die Basis für die Erstellung von Publikation für jegliche Formate und Distributionskanäle. MAM ist damit eine zunehmend wichtige Softwarekomponente der Informationsinfrastruktur von Unternehmen. Ein Medium stellt nur einen Wert (Asset) für ein Unternehmen dar, wenn es unkompliziert und schnell für den entsprechenden Einsatzzweck gefunden und verwendet werden kann. Diese Beschreibung stimmt mit den vier zentralen Eigenschaften des Media Asset Managements überein [8, Seite 32f]: Zugänglichkeit (Accessibility) muss gegeben sein. Das schnelle und einfache Wiederfinden von Media Assets Liquidität (Liquidity) Media Assets, die an ein Format oder eine Anwendung gebunden sind, sind für das Media Asset Management nutzlos. Daher müssen Media Assets für unterschiedliche Formate und Anwendungen anpassbar sein. 4

15 2. Media Asset Management System 5 Wiederverwendbarkeit (Reusability) Das Wiederverwenden von Media Assets spielt eine wesentliche Rolle. Nur Media Assets, die kostengünstig mehrfach eingesetzt werden können, sind von Relevanz. Skalierbarkeit (Scalability) Bei wachsender Anzahl der Media Assets oder Erweiterung der Speicherformate muss das Media Asset Management einsatz- und leistungsfähig bleiben. Neben der Erfüllung der oben angeführten Eigenschaften soll ein Media Asset Management zusätzlich folgende Standardfanforderungen umsetzen [8, Kapitel 10]: Media Assets müssen in ein MAMS eingespielt bzw. aus einem MAMS ausgelesen werden können. Media Assets müssen mit Metadaten versehen werden können. Die Bearbeitung der Metadaten von Media Assets innerhalb eines MAMS muss durchführbar sein. Ein MAMS muss die hierarchische Strukturierung der Media Asset unterstützen. In einem MAMS müssen Suchmechanismen für das gezielte Auffinden von Media Assets implementiert sein. Mit Hilfe eines MAMS müssen unterschiedliche Dateitypen verwaltet werden können. Die Datensicherheit der gespeicherten Media Assets muss innerhalb eines MAMS gewährleistet sein. 2.2 Begriffsabgrenzung In Verbindung mit Media Asset Management Lösungen treten oft die nachstehend aufgelisteten Begriffe auf, welche hier nach Oliver Kretzschmar und Roland Dreyer definiert werden [8, Seite 19f]. Bilddatenbank, Image-Management-System (IMS) Die Bilddatenbank repräsentiert die einfachste Form einer Mediendatenbank. Mit Hilfe einer Bilddatenbank können Bilder, Fotos und Grafiken verwaltet werden. Dokumenten-Management-System (DMS) Ein DMS wird zur Verwaltung von Dokumenten eingesetzt. Zu der Verwaltung von Dokumenten werden auch der Scannvorgang sowie die Übernahme der gescannten Dokumente in das DMS gezählt. Dabei ist für das DMS ausschließlich die Lesbarkeit der Informationen in Dokumenten relevant. Farbinformationen oder Informationen über die Papierqualität des Dokuments werden außer Acht gelassen. Produktionsdatenbank, Produktions-Management-System (PMS) Mit Hilfe eines PMS werden digitale Produktionsaufträge und die mit diesen Aufträgen verbundenen Medien verwaltet. Aufgrund der Verwaltung von Medien kann ein PMS auch als ein MAMS betrachtet werden.

16 2. Media Asset Management System 6 Web-Content-Management-System (WCMS) Das WCMS ist eine spezielle Ausprägung des CMS, das als Nächstes beschrieben wird. Es dient der Administration größerer Webseiten. Dies umfasst die Verwaltung von Medien (z. B. Bilder), die eigens für das Internet aufbereitetet sind. Außerdem unterstützt ein WCMS die redaktionelle Bearbeitung der Webseite. Content-Management-System (CMS) Im Gegensatz zu dem zuvor beschriebenen WCMS verwaltet ein CMS alle möglichen Medien bzw. Inhalte. Mit Hilfe eines CMS kann nicht nur der Ausgabekanal Internet, sondern auch eine Vielzahl anderer Ausgabekanäle bedient werden. Dazu zählen unter anderem Zeitung, Fernsehen und Radio. Entreprise-Content-Management-System (ECMS) Das ECMS ist eine neuere Form des CMS, das alle bestehenden Verwaltungssysteme vereinen will. Das herkömmliche CMS wird hierfür mit zusätzlichen Funktionalitäten, wie zum Beispiel mit der Anbindung an Archive, versehen. Des Weiteren ermöglicht ein ECMS die Verbindung der Firmenprodukte mit multimedialen Komponenten: Erstellung eines Webshops oder Druck eines Produktkatalogs. Knowledge-Management-System (KMS) Ein KMS dient der Verwaltung von Wissensinhalten. Mit dem Einsatz eines KMS soll die geschickte Verknüpfung von Informationen und vorhandenem Wissen erzielt werden. Im Informationszeitalter ist Wissensmanagement von hoher Bedeutung: Nur wer weiß, wie er die vorhanden Wissensressourcen nutzen kann, ist erfolgreich und der Konkurrenz einen Schritt voraus. Durch die häufige multimediale Präsentation von Wissensressourcen ist die Grenze zwischen KMS, WCMS, CMS und MAMS schwer zu ziehen. Gesamt betrachtet verschwimmt die Grenze zwischen den beschriebenen Systemen zunehmend. Die Funktionalitäten der unterschiedlichen Systeme überschneiden sich immer mehr. Außerdem konzentrieren sich die Systeme verstärkt auf die Integration von Arbeitsabläufen, wodurch eine Differenzierung zusätzlich erschwert wird.

17 Kapitel 3 Content im Media Asset Management System Mit Hilfe eines MAMS werden Media Assets verwaltet. Die Media Assets repräsentieren folglich den Content (deutsch: Inhalt) eines solchen Systems. Oliver Kretzschmar und Roland Dreyer sehen dabei den Ausdruck Asset als die Umschreibung eines Organisationsprinzips [8, Seite 18f]: Es besteht aus dem eigentlichen Inhalt, den Metadaten, die diesen Inhalt beschreiben, Kategorien und Klassifizierungen, die seinen Platz in der Welt bestimmen und Verknüpfungen, die seine Beziehungen zur Welt darstellen. Der Ausdruck Media konkretisiert den Inhalt der Assets. In diesem Fall handelt es sich um multimediale Dateien in digitaler Form: Bilder, Audiodateien, Videos, dreidimensionale Modelle, Textdokumente und dergleichen. Mit der Definition und der Einteilung von Content haben sich ebenso die Organisationen Society of Motion Picture and Television Engineers (SMPTE) und European Broadcasting Union (EBU) auseinandergesetzt. In einer eigens gegründeten Arbeitsgruppe wurde definiert, dass sich Content aus den folgenden zwei Komponenten zusammensetzt: Essenz und Metadaten [13, Seite 4]. Während die Essenz das eigentliche Programmmaterial in Form von Bildern, Audiodateien, Text oder Videos repräsentiert, beschreiben die Metadaten diese [13, Seite 4]: Essence in this context is the raw programme material itself, represented by pictures, sound, text, video, etc. The essence carries the actual message or information. [...] The second element is metadata. It is used to describe the actual essence and its different manifestations. Die Metadaten können dabei nach folgender Klassifizierung unterschieden werden: inhaltbezogene, materialbezogene und ortbezogene Metadaten. Inhaltbezogene Metadaten beschreiben die Essenz näher. Die materialbezogenen Metadaten geben unter anderem Aufschluss über das Dateiformat oder die Codierung der Essenz. Die lokalbezogenen Metadaten beinhalten etwa Informationen über den physischen Speicherplatz der Essenz [13, Seite 4]. In Zusammenhang mit Metadaten soll dem MPEG-7 Standard folgend kurz Aufmerksamkeit geschenkt werden. 7

18 3. Content im Media Asset Management System 8 MPEG-7 ist ein von der Moving Picture Experts Group entwickelter ISO/IEC Standard. Die zuvor verabschiedeten Standards MPEG-1, MPEG-2 und MPEG-4 repräsentieren multimediale Inhalte wie interaktive Videos für CD-ROMs oder digitales Fernsehen. Im Gegensatz dazu dient der MPEG-7 Standard, zuvor als Multimedia Content Description Interface bezeichnet, der Beschreibung multimedialer Inhalte. Dabei kann durch Programmcode oder Geräte (z. B. Laserscanner) die Beschreibung multimedialer Inhalte verarbeitet oder darauf zugegriffen werden. Es handelt sich bei dem MPEG-7 Standard folglich um keine Applikation. Das Ziel des MPEG-7 Standards ist es vielmehr von möglichst vielen verschiedene Applikationen verwendet zu werden [12]. Dem MPEG-7 Standard liegt eine Description Definition Language (DDL) zugrunde. Durch sie wird die Syntax für MPEG-7 verarbeitende Programme definiert. Außerdem spezifiziert sie den Einsatz von Extensible Markup Language (XML) Schemen, sodass sie dem MPEG-7 Standard entsprechen [13, Seite 98f]. Der Einsatz eines Standards zur Verwaltung von Media Assets trägt zur Standardisierung der gespeicherten Daten bei. Durch eine standardisierte Beschreibung von Daten kann unter anderem der Datenaustausch zwischen Unternehmen erleichtert werden. Die meisten Unternehmen haben jedoch spezielle Anforderungen an ein Metadatenbeschreibungsschema, sodass sie durch einen allgemeinen Standard wie MPEG-7 nicht erfüllt werden können. Aus diesem Grund können sich weder der MPEG-7 Standard noch andere Metadatenbeschreibungsschemen durchsetzen [13, Seite 92].

19 Kapitel 4 TEAPOT The Extendable Asset Persistent Object Store Dieses Kapitel stellt das Media Asset Management System TEAPOT vor. Nach einer kurzen Einführung in die Geschichte des Projekts werden allgemeine Informationen über das Projekt bekannt gegeben. 4.1 Geschichte Bei dem Media Asset Management System TEAPOT handelt es sich um ein bestehendes Projekt an der Fachhochschule Hagenberg. Das Herzstück von TEAPOT, die serverseitige Programmlogik, ist in Java implementiert und verwendet zur Persistierung der Daten das objektrelationale Abbildungswerkzeug Hibernate. Die grafische Benutzeroberfläche TEAPOT Web entstand im Zuge eines zweisemestrigen Studentenprojekts und gewann bei der Mediengala 2005 in der Kategorie Infomedia. Das Projekt galt damit als abgeschlossen. Da jedoch eine Reihe neuer Anforderungen aufgetreten sind, wurde im Herbst 2006 das Projekt TEAPOT Web erneut aufgenommen. Die Benutzeroberfläche sollte durch den Einsatz von Ajax (z. B. Implementierung einer Live-Suche) an den aktuellen Stand der Technik angeglichen werden. Das Ergebnis des Projekts war jedoch nur mäßig zufrieden stellend: Die in TEAPOT eingesetzten Technologien waren bereits veraltet und daher mit der neuen Technologie zum größten Teil inkompatibel. Um dennoch die Aktualisierung der Benutzeroberfläche durführen zu können, wurde für den Sommer 2007 die Generalüberholung von TEAPOT geplant. Das Projekt sollte durch den erstmaligen Einsatz des Spring Frameworks besser strukturiert und einfacher in der Handhabung (z. B. ausgelagertes Transaktionsmanagement) werden. Ferner sollte das eingesetzte Abbildungswerkzeug Hibernate auf die neueste Version aktualisiert werden. Die Änderungen sollten im bestehenden Code vorgenommen werden, was sich letztlich als eine unlösbare Aufgabe herausstellte. Aus diesem Grund wurde für den Herbst 2007 der Entschluss gefasst ein Reengineering von TEAPOT durchzuführen. Dies wird in einem Teil dieser Diplomarbeit dokumentiert. 9

20 4. TEAPOT The Extendable Asset Persistent Object Store Produktbeschreibung Bei TEAPOT handelt es sich um ein Media Asset Management System. Die serverseitige Programmlogik ist dabei von der Benutzerschnittstellenimplementierung unabhängig. Daher kann für TEAPOT jede beliebige Benutzerschnittstelle implementiert werden. Des Weiteren zeichnet sich TEAPOT dadurch aus, dass es quelloffen 1 angeboten wird. Der Programmcode kann eingesehen, verändert und erweitert werden. Ferner bedeutet dies, dass TEAPOT für jeden frei verfügbar und somit kostenlos ist.eine kostenpflichtige Version ist ausschließlich in Verbindung mit einer Domänenbereitstellung sowie einer umfassenden Kundebetreuung angedacht. Mit TEAPOT können Media Assets unterschiedlichster Dateitypen verwaltet werden: Audiodateien, Textdokumente, Bilder, dreidimensionale Modelle und Videos. Neben der Unterstützung zahlreicher Dateitypen bietet TEAPOT vielseitige Strukturierungsmöglichkeiten für Media Assets an. Die Media Assets können mit Schlagwörtern versehen werden. Außerdem werden Kategorien und Mediengruppen als hierarchische Strukturen angeboten. Um das schnelle Auffinden der Media Assets zu ermöglichen können die Media Assets mit zahlreichen Metadaten beschrieben werden. Mit der erweiterten Suche kann alle Metadaten eines Media Assets berücksichtigen. Zusätzlich kann die Suche auf bestimmte Kategorien und Mediengruppen eingeschränkt werden. Durch unzählige Erweiterungsmöglichkeiten ist TEAPOT flexibel. Die Implementierung neuer Funktionen wie die Versionierung von Media Assets oder das Hinzufügen von Schlagwortsynonyme ist dank einer gut strukturierten Programmlogik und deren strengen Trennung von der Benutzerschnittstellenimplementierung einfach zu realisieren. Genaueres zu den technischen Details sowie zu den konkreten Funktionen sind in den folgenden Teilen Server und Benutzeroberfläche zu erfahren. 1 Der englische Begriff Open Source wird mit quelloffen übersetzt. Quelloffen erfasst die Bedeutung von Open Source jedoch nicht vollständig. Unter anderem zählt die freie Verfügbarkeit eines Programms zu der Definition des englischen Begriffs. Weitere Informationen sind auf der Webseite der Open Source Initiative ( zu finden.

21 Kapitel 5 Stand der Technik (Server) Das Projekt TEAPOT setzt sich aus mehreren Komponenten zusammen. In dem Projektteil TEAPOT Core (deutsch: Kern, Herzstück) ist die serverseitige Implementierung umgesetzt. Dieser umfasst die Programmlogik für das Einspielen und Auslesen von Media Assets sowie für deren Verwaltung. Basierend auf der von TEAPOT Core angebotenen Schnittstelle können unterschiedliche Applikationen (z. B. eine Web- oder eine Desktopapplikation) erstellt werden. Da es sich bei TEAPOT um ein quelloffenes Projekt handelt, kann die serverseitige Implementierung jederzeit um neue Funktionalitäten erweitert werden. Zum jetzigen Zeitpunkt sind die folgenden Erweiterungen vorgesehen: eine Benutzerverwaltung, eine Synonymverwaltung für Schlagwörter und hierarchische Strukturen sowie eine Versions- und Variantenverwaltung. Projekte, die ähnliche Ziele verfolgen, sind unter anderem The Fedora Procject 1 und DAM- SEL 2. Diese beiden Projekte werden daher folgend näher betrachtet. Die Architektur von The Fedora Project basiert auf data objects (deutsch: Datenobjekte). Ein Datenobjekt setzt sich aus datastreams (deutsch: Datenströmen) und behaviors (deutsch: Verhaltensweisen) zusammen. Dabei besteht ein Datenstrom aus der Datei an sich und aus der Beschreibung der Datei durch Metadaten (siehe Allgemeines Content). Die Verhaltensweise beschreibt, wie der Datenstrom verarbeitet bzw. aufbereitet werden soll. Auf diese Weise kann der Datenstrom unter anderem für die Ausgabe in einer bestimmten Applikation aufbereitet werden. Es ist möglich einem Datenstrom beliebig viele Verhaltensweisen zuzuordnen [21]. Das The Fedora Project System besteht aus drei Schichten: den Web Services, dem Core Subsystem und dem Speicher. Die Web Services sind durch die Web Service Description Language (WSDL) beschrieben. Zu diesen Services zählen ein Management und ein Zugriff Service, wobei der Zugriff Service in zwei unterschiedlichen technischen Umsetzungen angeboten wird [21]. Das Core Subsystem implementiert die Web Services. Die Implementierung enthält unter anderem Operationen zur Erstellung und Bearbeitung von digitalen Inhalten. Außerdem werden Operationen für das Löschen, Importieren, Exportieren und Verwalten von digitalen Inhalten bereitgestellt [21]. Im Speicher Subsystem befinden sich die Operationen zum Lesen, Schreiben und Löschen von Daten aus dem Speicher [21]. Diese Schicht entspricht den Data Access Objekten von TEAPOT Core. Der elementarste Anwendungsfall von The Fedora Project ist die Verwaltung einfacher

22 5. Stand der Technik (Server) 12 Abbildung 5.1: Fedora: Standarddarstellung eines Profils für ein digitales Objekt (aus [21]). Inhaltsobjekte sowie der Zugriff auf diese. Dabei wird von den Standardeinstellungen des System Gebrauch gemacht, wodurch eine spezielle Systemkonfiguration nicht nötig ist [21]: The most elementary use of Fedora is management and access for simple content objects. This case is the "low barrier to entry" scenario for Fedora. It takes advantage of the default capabilities of the system, and does not require the creation of any special behavior definitions and behavior mechanisms. Digital Objects are simple containers for data and metadata. Digital object content can be accessed via "built-in" object behaviors. Einfache Inhaltsobjekte sind allein stehende Bilder, elektronische Dokumente, Audio- und Videodateien sowie andere Medientypen. Bei diesem elementaren Anwendungsfall können die Inhaltsobjekte auch mit Metadaten versehen werden. Ferner erlaubt dieser Anwendungsfall die einfache Erstellung von unterschiedlichen digitalen Sammlungen. Dabei kann die Darstellung der Inhaltsobjekte einer digitalen Sammlung angepasst werden. In Abbildung 5.1 ist gleichwohl das Standardaussehen von The Fedora Project dargestellt [21]. Der Einsatz von The Fedora Project ist dabei nicht auf den hier angeführten Anwendungsfall beschränkt. Durch die optionale Konfiguration von neuen Verhaltensweisen oder Datenströmen kann The Fedora Project auch individueller eingesetzt werden. Dennoch erfüllt The Fedora Project nicht alle Anforderungen an ein Media Asset Management System. Mit The Fedora Project ist es möglich digitale Inhalte zu verwalten und zu verteilen. Jedoch ist es nicht möglich digitale Inhalte in hierarchischen Strukturen zu verwalten. Dadurch ist in Bezug auf The Fedora Project die Implementierung eines eigenständigen Systems gerechtfertigt. DAMSEL (Digital Assets Management System for Electronic Libraries) ist das zweite Projekt, das ähnliche Ziele verfolgt. Es handelt sich dabei um eine Webapplikation, die in der Programmiersprache Java implementiert und an eine Datenbank angebunden ist. Für die Umsetzung von DAMSEL werden die folgenden Technologien eingesetzt: das Struts Webapplikationen Framework, der Jarkata Tomcat Applikationsserver, die MySQL Datenbankverwaltungssystem, und Java Server Pages. DAMSEL basiert auf freier Software und ist auch selbst ein quelloffenes Produkt. Ferner hält sich DAMSEL an geltende Standards.

23 5. Stand der Technik (Server) 13 Die Webapplikation unterstützt das Speichern und das Auslesen digitaler Inhalte aus dem System. Außerdem können digitale Inhalte kategorisiert und verwaltet werden. Ferner unterstützt die Webapplikation das Suchen sowie das Durchsuchen digitaler Inhalte [1]. Dieses Projekt erfüllt die wesentlichen Anforderungen an ein Media Asset Management System. Es ist dennoch keine brauchbare Alternative, da DAMSEL aufgrund des eingesetzten Struts Webapplikationen Framework ausschließlich als Webapplikation realisiert werden kann. Die Umsetzung einer anderen Applikationsform wird nicht unterstützt, wodurch auch in diesem Fall die Implementierung eines eigenständigen Systems gerechtfertigt ist.

24 Kapitel 6 Technologien In diesem Abschnitt werden jene Technologien beschrieben, die für die Entwicklung von TEA- POT Core eingesetzt werden. Zunächst wird das Spring Framework vorgestellt. Auf diesem Applikationsframework baut die Implementierung von TEAPOT Core auf. Danach werden zwei unterschiedliche objektrelationale Datenbankabbildungswerkzeuge beschrieben: Hibernate und ibatis. Zuletzt werden zwei unterschiedliche Datenbankmanagementsysteme vorgestellt: MySQL und PostgreSQL. Es werden jeweils zwei verschiedene Werkzeuge eingesetzt um unterschiedliche Umsetzungsmöglichkeiten zu testen. Ziel ist es herauszufinden, welche der vier möglichen Kombinationen sich für die Umsetzung eines Media Asset Management System am besten eignet. Das Ergebnis des Experiments wird im letzten Kapitel dieses Teils beschrieben. 6.1 Spring Framework Das Spring Framework 1 ist ein quelloffenes Applikationsframework, das auf der Programmiersprache Java basiert. Ziel des Spring Frameworks ist die Vereinfachung der Entwicklung mit Java sowie die konsistente und effektive Strukturierung gesamter Applikationen. Das Spring Framework greift zum Teil auf bewährte Frameworkkomponenten zurück. Dadurch wird deren Zusammenspiel innerhalb einer stimmigen Architektur ermöglicht [7, Seite 1]: Spring is an application framework. Unlike single-tier frameworks such as Struts or Hibernate, Spring aims to help structure whole applications in a consistent, productive manner, pulling together best-of-breed single-tier frameworks to create a coherent architecture. Ferner ermöglicht das Spring Framework durch die Unterstützung eines einheitlichen Programmiermodells den vielseitigen Einsatz der Programmlogik sowie der Plain Old Java Objects 2 (POJOs). Mit dem Spring Framework eigenen Modul MVC 3 Web Framework kann beispielsweise eine Webapplikation angebunden werden. Das MVC Web Framework ist jedoch nur eines von vielen Modulen. Dem Spring Framework können noch weitere Module zugeordnet werden. Die wichtigsten Module, die auch die Plain Old Java Object, kurz POJO, ist eine Bezeichnung für ein einfaches Java Objekt 3 Model View Controller 14

25 6. Technologien 15 Prinzipien des Spring Frameworks widerspiegeln, werden folgend beschrieben [7, Seite 5 und 8f]: Umkehrung der Kontrolle, Zuweisung von Abhängigkeiten (Inversion of Control (IoC) Container, Dependency Injection) Am treffendsten wird das Prinzip der Inversion of Control durch den Satz Don t call me, I ll call you. (deutsch: Ruf mich nicht an, ich ruf dich an.) erklärt. Damit wird eine push Konfiguration umschrieben. Das Spring Framework weist dabei den Applikationsobjekten zur Laufzeit die Abhängigkeiten zu. Seit 2003 wird für dieses Prinzip die spezifischere Bezeichnung Dependency Injection geprägt. Aspektorientierte Programmierung (AOP) (Aspect-Oriented Programming Framework) Durch die aspektorientierte Programmierung werden standardisierte Verhalten des Spring Frameworks, wie zum Beispiel das deklarative Transaktionsmanagement, vom restlichen Quellcode isoliert. Dabei können die im deklarativen Transaktionsmanagement gekapselten Methoden überall im Quellcode unabhängig vom Programmkontext eingesetzt werden. Auf diese Weise wird unter anderem Quellcodeverdoppelung vermieden. 6.2 Objektrelationale Datenbankabbildungswerkzeuge Dieser Abschnitt beschreibt die objektrelationalen Datenbankabbildungswerkzeuge Hibernate und ibatis. Dabei wird auf die Eigenschaften sowie auf die Unterschiede der beiden Werkzeuge eingegangen. Zwei Quellcodebeispiele dienen zur Verdeutlichung der Beschreibung Hibernate Das objektrelationale Datenbankabbildungswerkzeug Hibernate 4 arbeitet auf Ebene der Persistenzklassen (siehe Abbildung 6.1 auf der nächsten Seite). Dabei werden die benötigten SQL- Abfragen von Hibernate im Hintergrund generiert. Datenbankspezifische Eigenschaften werden Hibernate durch die Konfiguration eines Datenbankdialektes bekannt gegeben [7, Seite 270]: As a full-blown O/R mapping tool, Hibernate works at the persistent class level, rather than at the statement level. The corresponding SQL statements are generated under the hood. Database specifics such as identity generation are abstracted through a configurable database dialect. Da Hibernate nicht auf Ebene der SQL-Abfragen arbeitet, kann es auch ohne nähere Kenntnisse über die Abfragesprache der eingesetzten Datenbank verwendet werden. Durch die Generierung der SQL-Abfragen geht jedoch hier der Einfluss des Entwicklers verloren. Die SQL- Abfragen werden ferner in einer Form generiert, die für Maschinen gut zu verarbeiten ist. Das Lesen der generierten SQL-Abfragen ist für einen Menschen mühsam. Bei dem objektrelationalen Datenbankabbildungswerkzeug ibatis ist genau das Gegenteil der Fall (siehe Abschnitt 6.2.2). Der Quellcode in Abbildung 6.1 auf der nächsten Seite zeigt die Abbildung der Tabelle Category auf die Persistenzklasse teapot.businessobject.category von TEAPOT Core. Diese Abbildung der Datenbanktabelle ist in einer XML-Datei gespeichert. Der Speicherort 4

26 6. Technologien 16 1 <hibernate-mapping> 2 <class name="teapot.businessobject.category" table="category"> 3 <id name="id" column="id" type="string"> 4 <generator class="assigned"/> 5 </id> 6 <property name="categoryname" column="categoryname" type="string" /> 7 <property name="categorydescription" column="categorydescription" type="string"/> 8 <many-to-one name="domain" class="teapot.businessobject.domain" column="fk_domain" not-null="true"/> 9 <many-to-one name="supercategory" class="teapot.businessobject.category" column=" fk_parent"/> 10 <set name="assets" table="asset_category" inverse="true"> 11 <key column="fk_category" /> 12 <many-to-many column="fk_asset" class="teapot.businessobject.asset"/> 13 </set> 14 <set name="keywords" table="category_keyword"> 15 <key column="fk_category" /> 16 <many-to-many column="fk_keyword" class="teapot.businessobject.keyword"/> 17 </set> 18 </class> 19 </hibernate-mapping> Abbildung 6.1: Abbildung der Tabelle Category für Hibernate. der Datei wird dem Programm bekannt gegeben, sodass die Abbildung der Datenbank vor Programmstart eingelesen werden kann. Basierend auf diesen Informationen kann das Programm in Verbindung mit Hibernate schließlich die benötigten SQL-Abfragen generieren. Als Komplettpaket für objektrelationale Datenbankabbildung ist Hibernate eine gute Wahl. Dabei sind die mächtigen Abbildungsmöglichkeiten sowie die eigene SQL-ähnliche Abfragesprache die größten Stärken des Datenbankabbildungswerkzeugs. Die Nachteile von Hibernate sind in erster Linie Nachteile von objektrelationaler Datenbankabbildung im Allgemeinen. Zu den Nachteilen zählen unter anderem die Komplexität der automatischen Veränderungserkennung und die strengeren Anforderungen für das Nachladen von Objekten (Lazy Loading) [7, Seite 288]: Hibernate is an excellent option for full-fledged O/R mapping. Its greatest strengths are the powerful mapping facilities and the SQL-style query language. Its disadvantages are mainly drawbacks of full-fledged O/R mapping in general: the complexity of automatic change detection, and stricter requirements for lazy loading ibatis Das objektrelationale Datenbankabbildungswerkzeug ibatis 5 basiert auf dem Einsatz von SQL Maps: In einer XML-Datei werden SQL-Abfragen definiert, die mit Platzhaltern versehen sind (siehe Abbildung 6.2 auf der nächsten Seite). Bei der Ausführung eines Programms, das ibatis verwendet, werden die Platzhalter durch spezifische Werte ersetzt. Das Resultat einer SQL-Abfrage wird in einem Objekt mit vordefinierten Parametern gespeichert [7, Seite 261]: 5

27 6. Technologien 17 1 <insert id="insertcategory" parameterclass="category"> 2 INSERT INTO category (id, categoryname, categorydescription, 3 fk_parent, fk_domain) VALUES (#id#, #categoryname#, 4 #categorydescription#, #parentcategoryid#, #domainid#) 5 </insert> Abbildung 6.2: Definition einer Abfrage in einer ibatis SQL Map. The basic idea of SQL Maps is simple: Statements are defined in an XML file, specifying an SQL string with parameter placeholders (optionally specifying SQL types and other details for the parameters). On execution, the placeholders are resolved to given parameter values, either from a parameter map, a JavaBean with bean properties, or a simple parameter object. In case of an SQL query, the definition maps result columns to a result object, supporting the same kinds of values as for parameters. Durch die Auslagerung der Abfragen in XML-Dateien können diese zentral und unabhängig vom restlichen Quellcode verwaltet werden. Im Gegensatz zu dem objektrelationale Datenbankabbildungswerkzeug Hibernate muss der Entwickler hier der Datenbankabfragesprache mächtig sein, da er die Abfragen selbst schreiben muss. Die Definition einer Abfrage für iba- TIS ist in Abbildung 6.2 dargestellt. Das Konzept von ibatis ist simpel und dennoch mächtig. Verglichen mit Hibernate gibt es keine eigene Abfragesprache, die erlernt werden muss. Ferner läuft bei ibatis keine automatische Veränderungserkennung im Hintergrund, wodurch die Systemomplexität reduziert ist [7, Seite 268]: The beauty of ibatis SQL Maps is its simplicity. Externalizing SQL statements and their result and parameter mappings into an XML file is a simple but nevertheless powerful concept. In contrast to Hibernate [...], there is no special query language to learn and no automatic change detection working in the background, which means that there is less complexity to deal with. Obwohl ibatis durch die Definition aller benötigen Datenbankabfragen auf den ersten Blick einen vermehrten Arbeitsaufwand vermuten lässt, hat dieses Konzept den Vorteil der kompletten Kontrolle über die abzusetzenden Datenbankabfragen. Ab einem bestimmten Projektumfang ist jedoch davon abzuraten, ibatis als objektrelationales Datenbankabbildungswerkzeug einzusetzen. Es ist nicht zwingend ein Vorteil, dass ibatis über keine eigene Abfragesprache verfügt. Müssen unterschiedliche Datenbanken an ein Programm angebunden werden, muss der Entwickler die definierten Abfragen unter Umständen an die datenbankspezifischen Eigenschaften anpassen. Im Vergleich zu Hibernate bietet ibatis mehr Kontrolle über die abzusetzenden Datenbankabfragen. In der Vielseitigkeit und Flexibilität ist ibatis jedoch keine Konkurrenz für Hibernate.

28 6. Technologien Datenbankmanagementsysteme In diesem Abschnitt werden die Datenbankmanagementsysteme MySQL und PostgreSQL beschrieben. Dabei wird auf die Eigenschaften und die Unterschiede der beiden Systeme eingegangen MySQL MySQL 6 ist ein relationales Datenbankmanagementsystem und ist als quelloffene Software für unterschiedliche Betriebssysteme verfügbar [14]. MySQL bietet über den Datenbanktreiber InnoDB transaktionssichere Lese- und Schreibzugriffe an. Dies wird durch Sperren auf einzelne Datensätze gewährleistet. Das bedeutet, dass zwei Benutzer parallel unterschiedliche Datensätze einer Tabelle bearbeiten können. Dies fördert die Mehrbenutzerfähigkeit und steigert die Performanz. Eine weitere wichtige Eigenschaft von InnoDB ist die Überprüfung von Fremdschlüsselbeziehungen. Dadurch wird die Konsistenz der Datenbank gewährleistet [14]. Der Datenbanktreiber MyISAM bietet zwar einen schnelleren schreibenden Zugriff auf Tabellen, unterstützt jedoch keine Fremdschlüsselbeziehungen. Ferner hat MyISAM keine Unterstützung bei Transaktionen. Aufgrund dieser fehlenden Eigenschaften wurde MyISAM als Datenbankmanagementsystem in Verbindung mit MySQL ausgeschlossen [14] PostgreSQL PostgreSQL 7 ist ein relationales Datenbankmanagementsystem und ist als quelloffene Software verfügbar. Ferner ist PostgreSQL weitgehend mit dem Standard ANSI-SQL 92 konform [23]. Wie MySQL mit dem Datenbanktreiber InnoDB (siehe Abschnitt 6.3.1) bietet auch PostgreSQL transaktionssichere Lese- und Schreibzugriffe. Dies umfasst ebenso die Verwaltung von parallelen Datenbankzugriffen. Eine weitere Gemeinsamkeit mit InnoDB ist die Überprüfung von Fremdschlüsseln, wodurch die Konsistenz der Datenbank garantiert ist. Zusätzlich bietet PostgreSQL weitere spezielle Funktionen wie gespeicherte Prozeduren an. Für die Implementierung von TEAPOT Core sind allerdings nur Fremdschlüsselbeziehungen und Transaktionsmanagement relevant [23]

29 Kapitel 7 Anforderungen Dieses Kapitel gibt einen Überblick über die Anforderungen an TEAPOT aus Sicht des Entwicklers. Zunächst wird beschrieben, welche Art von Media Assets in TEAPOT gespeichert werden können. Danach werden verschiedene Strukturen beschrieben, die zur Verwaltung der Media Assets dienen. Da die Suche ein wesentliches Merkmal eines Media Asset Management Systems ist, wird ihr ein Unterabschnitt gewidmet. Zuletzt werden die Anwendungsfälle zusammengefasst. 7.1 Media Assets Als Media Asset Management System ist TEAPOT dafür vorgesehen Media Assets zu speichern und zu verwalten. Die folgende Auflistung gibt einen kurzen Überblick darüber, welche Media Assets gespeichert werden können und über welche Metadaten sie verfügen. Allgemeines zu allen Media Assets Für alle Arten von Media Assets sind diese Informationen gleich: Id, Timestamp, Name, Beschreibung, URL, URL zu einer Vorschau, MIME-Type und Qualität. Audio Asset Ein Audio Asset verfügt über folgende zusätzliche Informationen: Dauer, Anzahl der Audiokanäle, Audio-Codex, Audio-Frames pro Sekunde, Audio-Samples pro Sekunde, Audio-Bits pro Sekunde, Audio-Bits pro Frame und Audio-Bits pro Sample. Document Asset Ein Document Asset verfügt im Moment über keine zusätzlichen Informationen. Sollte zusätzliche Informationen benötigt werden, können diese jederzeit nachträglich eingefügt werden. Image Asset Höhe. Ein Image Asset verfügt über folgende zusätzliche Informationen: Breite und Model Asset Ein Model Asset verfügt über folgende zusätzliche Informationen: Frames und Anzahl der Polygone. 19

30 7. Anforderungen 20 Abbildung 7.1: Beispiel für eine Anwendung. Video Asset Ein Video Asset verfügt über folgende zusätzliche Informationen: Dauer, Breite, Höhe, Video-Codex, Video-Frames pro Sekunde, Video-Bits pro Sekunde, Anzahl der Audiokanäle, Audio-Codex, Audio-Frames pro Sekunde, Audio-Samples pro Sekunde, Audio-Bits pro Sekunde, Audio-Bits pro Frame und Audio-Bits pro Sample. 7.2 Strukturen Zur übersichtlicheren Verwaltung der Media Assets stellt TEAPOT unterschiedliche Strukturen zur Verfügung. Die folgende Aufzählung beschreibt die Strukturen näher. Domäne (Domain) Die Domäne ist eine einfache Struktur und verfügt über die folgenden Informationen: Id, Name und Beschreibung. Sie kann die folgenden Elemente enthalten: Media Asset, Schlagwort, Kategorie und Mediengruppe. Domänen können nur nebeneinander existieren. Sie können nicht verschachtelt werden. Abbildung 7.1 zeigt die Verwendung von Domänen. Des Weiteren zeigt diese Abbildung den Zusammenhang zwischen einer Domäne und den in ihre enthaltenen Kategorien. Bei der Erstellung einer Domain, wird automatisch eine Standardkategorie erzeugt. Die Standardkategorie enthält alle anderen Kategorien. Wird eine Kategorie gelöscht, kann entschieden werden, ob die Media Assets in die Standardkategorie verschoben werden oder ob die Media Assets gelöscht werden. Kategorie (Category) Die Kategorie ist eine hierarchische Struktur und verfügt über folgende Informationen: Id, Name, Beschreibung und Elternkategorie. Eine Kategorie kann beliebig viele Unterkategorien, aber immer nur genau eine Elternkategorie haben. Des Weiteren gehört eine Kategorie immer nur genau zu einer Domäne.

31 7. Anforderungen 21 Mediengruppe (Mediagroup) Die Mediengruppe ist eine hierarchische Struktur. Sie repräsentiert eine Gruppierung eines bestimmten, selbst definierten Mediengruppentyps (siehe Mediengruppentyp). Eine Mediengruppe kann beliebig viele Untergruppen haben. Jede Mediengruppe kann jedoch immer nur eine Elternmediengruppe haben. Diese Struktur verfügt über die folgenden Informationen: Id, Name, Beschreibung, Elternmediengruppe und Mediengruppentyp. Die Idee von Mediengruppen soll anhand eines Beispiels kurz skizziert werden: Ein Benutzer möchte ein Videoprojekt in TEAPOT einspielen. Dieses Videoprojekt enthält Videobänder, auf denen sich einzelne Videoclips befinden. Um dieses Videoprojekt mit dieser Strukturierung in TEAPOT zu übernehmen, erstellt der Benutzer folgende Mediengruppentypen: Videoprojekt und Videoband. Die Mediengruppentypen werden in einer eigenen Tabelle verwaltet und von der Tabelle für Mediengruppen lediglich referenziert. Im nächsten Schritt legt der Benutzer eine Mediengruppe mit dem Namen Werbefilme an und weist dieser Mediengruppe den zuvor erstellten Mediengruppentyp Videoprojekt zu. Danach definiert der Benutzer eine weitere Mediengruppe, die den Namen Werbefilme Videoband 1 erhält. Der Medientyp dieser Mediengruppe ist Videoband. Die Mediengruppe mit dem Namen Werbefilme Videoband 1 ist somit eine Untergruppe der Mediengruppe mit dem Namen Werbefilme. Nach dem Erstellen der benötigten Projektstruktur kann der Benutzer nun die vorhandenen Media Assets der Mediengruppe Werbefilme Tape 1 zuordnen. Dabei repräsentiert jedes zugeordnete Media Asset einen Videoclip. Zukünftig können beliebig viele Mediengruppen mit den Mediengruppentypen Videoprojekt oder Videoband erstellt werden. Auf diese Weise können mehrere verschiedene Videoprojekte strukturiert werden. Abschnitt (Verwaltung von Strukturen) unter einem anderen Aspekt dieser Thematik. Mediengruppentyp (Mediagrouptype) Die Bedeutung von Mediengruppentypen wird bereits im vorangehenden Absatz Mediengruppe deutlich. Ferner ist zu erwähnen, dass auch Mediengruppentypen hierarchisch abgespeichert werden können. Bei Bedarf können jederzeit neue Mediengruppentypen erstellt werden. Schlagwort (Keyword) Das Schlagwort ist eine einfache Struktur und verfügt über folgende Informationen: Id und Name. Ein Schlagwort kann einem Media Asset, einer Kategorie und einer Mediengruppe hinzugefügt werden. Wird ein Schlagwort einer Kategorie oder einer Mediengruppe hinzugefügt, so gilt dieses Schlagwort auch für jene Media Assets, die in dieser Kategorie oder Mediengruppe enthalten sind. 7.3 Die Suche als Mittelpunkt des MAMS Die Suche ist der zentrale Punkt des Media Asset Management Systems. Denn nur schnell auffindbare Media Assets werden von Benutzern weiter verwendet (vgl.. Kapitel 2). Aus diesem Grund wird diesem Teil des Media Asset Management Systems TEAPOT besondere Aufmerksamkeit geschenkt. Um für TEAPOT eine schnellstmögliche Suche anzubieten wur-

32 7. Anforderungen 22 den unterschiedliche Technologiekombinationen in Bezug auf die Suche getestet. In Kapitel 9 werden die Ergebnisse dieser Geschwindigkeitsmessungen diskutiert. In TEAPOT werden zwei verschiedene Arten von Suchen unterstützt: eine einfache Suche und eine erweiterte Suche. Bei der einfachen Suche handelt es sich um eine Schlagwortsuche. Der Benutzer gibt in das Suchfeld ein oder mehrere beliebige Schlagworte ein. Nach Absetzen der Sucheanfrage wird nach Media Assets gesucht, die das eingegebene Schlagwort in ihrem Namen, in ihrer Beschreibung oder aber als Schlagwort haben. Die einfache Schlagwortsuche ist demzufolge eine ODER-Suche. Die erweiterte Suche berücksichtigt speziell die Metadaten der Media Assets. Dabei kann eine erweiterte Suche über alle oder über einzelne Medientypen abgesetzt werden. Bei der erweiterten Suche über alle Medientypen kann das Ergebnis dennoch auf bestimmte Medientypen eingeschränkt werden. Dabei werden jedoch nur jene Metadaten beachtet, die für alle Medientypen gleich sind (z. B. Name oder Qualität eines Media Assets). In beiden Fällen kann der Benutzer die Suche auf bestimmte Kategorien und Mediengruppen einschränken. Ferner handelt es sich hierbei um eine UND-Suche. 7.4 Anwendungsfälle In diesem Abschnitt werden zunächst die Akteure für TEAPOT beschrieben. Folgend werden die Anwendungsfälle für TEAPOT zusammengefasst. In der Beschreibung der Anwendungsfälle werden unter anderem die beteiligten Akteure angegeben. Dadurch ist die einmalige Definition der Akteure grundlegend Akteure Für jeden Anwendungsfall (siehe Abschnitt 7.4.2) wird angegeben, welche Akteure die beschriebenen Aktion durchführen können. Aus diesem Grund werden folgend die elementaren Akteure für TEAPOT beschrieben. Für den späteren Betrieb von TEAPOT ist vorgesehen, dass auch weitere Akteure definiert werden können. Gast Ist ein System öffentlich zugänglich, hat ein Gast Leserecht. Ist das System ausschließlich für registrierte Benutzer zugelassen, verfügt ein Gast über keinerlei Rechte. Registrierter Benutzer Ein registrierter Benutzer hat neben dem Leserecht auch das Recht Dateien aus dem System herunterzuladen. Redakteure Ein Redakteur darf alles, was auch ein registrierter Benutzer in dem System darf. Darüber hinaus kann er für ihn freigegebene Verwaltungsaufgaben innerhalb einer Domäne übernehmen. Chefredakteur Dieser Akteur hat alle Rechte, die auch ein Redakteur hat. Darüber hinaus ist er für die gesamte Verwaltung einer Domäne verantwortlich. Er kann alle Verwaltungsaufgaben selbst durchführen oder aber an von ihm bestimmte Redakteure delegieren.

33 7. Anforderungen 23 Abbildung 7.2: Beispiel für einen Anwendungsfall. Administrator Ein Administrator hat innerhalb einer Domäne die gleichen Rechte, die auch ein Chefredakteur hat. Darüber hinaus obliegt ihm die Verwaltung des gesamten Systems. Er kann neue Domänen anlegen, bearbeiten und löschen Anwendungsfälle Die Anwendungsfälle spezifizieren die Interaktion zwischen den zuvor beschriebenen Akteuren (siehe Abschnitt 7.4.1) und TEAPOT. Ein Anwendungsfall beschreibt dabei genau einen Handlungsablauf. Die Beschreibung eines Anwendungsfalles umfasst die folgenden Komponenten: eine Kurzbeschreibung, eine Definition der Vor- und Nachbedingungen des Handlungsablaufes, eine Beschreibung der möglichen Fehlersituationen während des Handlungsablaufes sowie die Nachzustände für diese Fehlersituationen, die beteiligten Akteure und eine detaillierte Beschreibung des Handlungsablaufes. Abbildung 7.2 zeigt als Beispiel einen für TEAPOT spezifizierten Anwendungsfall. Dieser beschreibt das Anlegen eines neuen Schlagwortes für TEAPOT. Neben dem in Abbildung vorgestellten Anwendungsfall sind für TEAPOT außerdem die folgenden Anwendungsfälle spezifiziert: Domäne Domäne anlegen, Domäne bearbeiten, Domäne löschen

34 7. Anforderungen 24 Kategorie Kategorie anlegen, Kategorie bearbeiten, Kategorie löschen Media Asset Media Asset anlegen, Media Asset auslesen, Media Asset bearbeiten, Media Asset löschen, Media Asset einfach und erweitert suchen Mediengruppe Mediengruppe anlegen, Mediengruppe bearbeiten, Mediengruppe löschen Mediengruppentyp Mediengruppentyp anlegen, Mediengruppentyp bearbeiten, Mediengruppentyp löschen Schlagwort Schlagwort anlegen (siehe Abbildung 7.2 auf der vorherigen Seite), Schlagwort bearbeiten, Schlagwort löschen Auf der beigelegten DVD ist die ausführliche Beschreibung der hier angeführten Anwendungsfälle zu finden. Dabei gehen alle dort beschriebenen Anwendungsfälle davon aus, dass ein Benutzer die nötigen Rechte hat. Außerdem wird vorausgesetzt, dass Operationen, die einem Benutzer aufgrund fehlender Rechte nicht erlaubt sind, dem Benutzer nicht angeboten werden. Aus diesem Grund gibt es hierfür keine separat beschriebenen Fehlersituationen. Bei Löschoperationen wird der Benutzer vor dem endgültigen Löschen durch einen Dialog darauf hingewiesen, dass ein Objekt endgültig entfernt wird. Er kann den Vorgang an dieser Stelle abbrechen oder bestätigen. Beim Bestätigen wird das Objekt endgültig gelöscht.

35 Kapitel 8 Umsetzung Dieses Kapitel widmet sich der technischen Umsetzung von TEAPOT Core. Zunächst wird TEAPOT Core in der allgemeinen Systemarchitektur positioniert. Anschließend wird das Datenbankmodell, auf dem TEAPOT Core aufbaut, erläutert. Zuletzt wird die detaillierte Architektur von TEAPOT Core betrachtet. 8.1 Allgemeine Systemarchitektur In Abbildung 8.1 auf der nächsten Seite ist die allgemeine Systemarchitektur von TEAPOT schematisch dargestellt. Die oberste Ebene ist die Benutzeroberfläche (Client Application). Für die Umsetzung der Benutzeroberfläche können unterschiedliche Techniken eingesetzt werden. Ein Beispiel für die Umsetzung einer möglichen Benutzeroberfläche ist eine Webapplikation wie sie in einem Teil dieser Diplomarbeit vorgestellt wird. Eine andere Option wäre eine Desktopapplikation. Damit dies möglich ist wird eine einheitliche Programmierschnittstelle (API) angeboten. Dies ist jener Teil von TEAPOT Core, der nach außen hin bekannt ist und von Entwicklern für die Erstellung von Applikationen verwendet werden kann. Hinter dieser Programmierschnittstelle verbirgt sich das Herzstück TEAPOT Core, der die gesamte Programmlogik von TEAPOT enthält. Die genaue Architektur von TEAPOT Core wird in Abschnitt 8.3 näher betrachtet. TEAPOT Core ist an eine Datenbank (Database) angebunden. In der Datenbank sind die Metadaten zu den Media Assets gespeichert. Außerdem sind in der Datenbank die verschiedenen Strukturen sowie deren Beziehungen untereinander und zu den Media Assets gespeichert. Eine ausführliche Beschreibung des Datenmodells wird in Abschnitt 8.2 angeboten. Die unterste Schicht (Media Storage) repräsentiert den physischen Speicher für die Essenz der Media Assets. Das bedeutet, dass hier die Mediendateien gespeichert sind. Es wurde zunächst überlegt diese Schicht wegzulassen und die Mediendateien als BLOBs (Binary Large Objects) direkt in der Datenbank zu speichern. Der Vorteil dieser Variante ist, dass die Datenbank inklusive der Mediendateien leichter transportierbar ist. Näher betrachtet ist es jedoch sinnvoller, die Mediendateien nicht in der Datenbank zu speichern: Große Medien-Dateien wie reprofähige Bild-Dateien, Video- und Audio-Streams werden in der Regel nicht in der Datenbank (z. B. als Datenbank-BLOB) selbst gespeichert, sondern nur als Verweis (Link) verwaltet, der mit wenigen Bytes auskommt. Zum einen, weil die meisten Anwendungen wie Adobe Photoshop, Adobe 25

36 8. Umsetzung 26 Abbildung 8.1: TEAPOT Systemarchitektur. Illustrator, QuarkXPress kein Öffnen von Dateien aus einem Datenbank-Stream heraus unterstützen. [...] Zum anderen lässt sich durch das physikalische Vorhandensein der Medien-Dateien in der File-Server-Struktur die Plattenkapazität des File-Servers durch Archivierungstechnologien (hierarchisches Speichermanagement, Nearline- und Offline-Speicher) erweitern. Ein weiterer Grund ist die geforderte Verfügbarkeit der Medien-Dateien auch im Falle der Nicht-Verfügbarkeit der Medien-Datenbank selbst [8, Seite 81]. Hinzu kommt die schnell anwachsende Datenmenge in der Datenbank, die durch das Abspeichern der Mediendateien als BLOBs verursacht wird. Dies beeinträchtigt die Performanz der Datenbank insbesondere bei der Suche nach Media Assets. Ferner bedeutet dies auch zeitlichen Mehraufwand beim Sichern der Datenbank. Das Rückspielen einer Sicherung dauert ebenso erheblich länger. Aus den hier angeführten Gründen wurde für die Mediendateien letztlich ein physischer Speicher als Speicherort ausgewählt. 8.2 Datenmodell In Abbildung 8.2 auf der nächsten Seite ist das Datenmodell von TEAPOT dargestellt. Für die Abbildung der Media Assets (blau gerahmt) wird das Entwurfsmuster (Design Pattern) der Class Table Inheritance (vgl. [4]) verwendet. Für jede Klasse in der Vererbungshierarchie der Media Assets (siehe Abbildung 8.7 auf Seite 31) gibt es eine Tabelle in der Datenbank. Die Tabelle asset fasst die allgemein gültigen Metadaten der Media Assets zusammen. In den spezifischen Media Asset Tabellen sind die zusätzlichen Metadaten zu den einzelnen Medientypen gespeichert. Daraus ergibt sich Folgendes: Ein Audio Asset ist ein Media Asset, das über zusätzliche Metadaten verfügt. Daher wird die Tabelle asset von der Tabelle audioasset referenziert. Dies gilt ebenso für die anderen Typen von Media Assets. Der Typ eines Media Assets ist zusätzlich durch eine Ziffer in der Tabelle asset gespeichert. Die Bedeutung dieser Ziffer ist im Code mit finalen statischen Variablen definiert (siehe Abbildung 8.3 auf Seite 28). Ein Media Asset gehört zumindest einer Kategorie (Tabelle category) an. Es kann aber auch mehreren Kategorien zugeordnet werden. Außerdem kann ein Media Asset einer oder

37 8. Umsetzung 27 Abbildung 8.2: Datenmodell.

38 8. Umsetzung 28 1 public final static int AUDIOASSET = 0; 2 public final static int DOCUMENTASSET = 1; 3 public final static int IMAGEASSET = 2; 4 public final static int MODELASSET = 3; 5 public final static int VIDEOASSET = 4; Abbildung 8.3: Definition der verschiedenen Typen von Media Assets in der Klasse Asset. mehreren Mediengruppen (Tabelle mediagroup) angehören. Das Gleiche gilt für die Schlagwörter (Tabelle keyword). Diese Beziehungen sind wechselseitig: Auch ein Schlagwort, eine Kategorie oder eine Mediengruppe kann ein oder mehrere Media Assets enthalten. Die Abbildung dieser Beziehungen erfolgt über die Zwischentabellen asset_category, asset_keyword und asset_mediagroup. Dabei wird von diesen Tabellen auf Seiten der Media Assets stets die Tabelle asset referenziert. Das Datenmodell sieht vor, dass Kategorien und Mediengruppen Schlagwörter zugewiesen werden können. Dabei kann eine Kategorie bzw. eine Mediengruppe über ein oder mehrere Schlagwörter verfügen. Es handelt sich hierbei ebenfalls um eine wechselseitige Beziehung: Einem Schlagwort können mehrere Kategorien und Mediengruppen zugeordnet werden. Diese Beziehungen werden über die Zwischentabellen category_keyword und mediagroup_keyword abgebildet. Eine Mediengruppe verfügt stets über genau einen Mediengruppentyp (Tabelle mediagrouptype). Ein Mediengruppentyp kann jedoch mehreren Mediengruppen zugeordnet sein. Bei dem Mediengruppentyp handelt es sich wie auch bei der Mediengruppe und der Kategorie um eine hierarchische Struktur. Aus diesem Grund verfügen die zugehörigen Tabellen jeweils über ein Feld, in dem optional die ID eines Elternelements gespeichert werden kann. Dazu referenzieren sich diese Tabellen jeweils selbst. Mit Ausnahme der spezifischen Media Asset Tabellen verfügt jede der hier vorgestellten Datentabellen über eine Referenz zu einer Domäne (Tabelle domain). Eine Domäne kann dabei jeweils mehrere Kategorien, Media Assets, Mediengruppen, Mediengruppentypen und Schlagwörter enthalten. Die einzelnen Objekte können jedoch ausschließlich einer Domäne zugeordnet sein. Bei dem ersten Entwurf waren die Beziehungen von Kategorien, Mediengruppen, Mediengruppentypen und Schlagwörter zu einer Domäne in Zwischentabellen abgebildet. Die Beziehung eines Media Assets zu einer Domäne sollte in diesem Modell nicht separat gespeichert werden. Durch die verpflichtende Zuordnung eines Media Assets zu einer Kategorie wäre die Domäne für ein Media Asset definiert gewesen. Der Vorteil dieses Ansatzes wäre, dass es keine redundanten Informationen in den Tabellen für Kategorien, Mediengruppen, Mediengruppentypen und Schlagwörter gegeben hätte. Die Umsetzung dieses Ansatzes war jedoch nicht möglich. Im folgenden Beispiel wird erläutert, warum diese Idee nicht umgesetzt werden konnte. Es sind zwei verschiedene Domänen in dem Media Asset Management System TEAPOT vorhanden. Die Domänen seien mit A und B bezeichnet. Person A legt für Domäne A die Kategorie Tiere an. Als Unterkategorie für die Kategorie Tiere erstellt Person A die Kategorie Katzen. Person B legt für Domäne B die Kategorie Lebewesen an. Als Unterkategorie für

39 8. Umsetzung 29 Abbildung 8.4: Zwischentabelle für die Beziehung zwischen Schlagwort (Keyword) und Domäne (Domain). Abbildung 8.5: Ohne Zwischentabelle für die Beziehung zwischen Schlagwort (Keyword) und Domäne (Domain). die Kategorie Lebewesen möchte Person B die Kategorie Katzen anlegen. Da die Kategorie Katzen im Media Asset Management System bereits vorhanden ist, wird auf diese Kategorie zurückgegriffen. Hier kommt es jedoch zu einem Problem: Person A hat die Kategorie Katzen bereits als Unterkategorie für die Kategorie Lebewesen bestimmt. Aus diesem Grund ist das Arbeiten mit einer Zwischentabelle für die Beziehung zwischen Kategorien und Domänen nicht vorteilhaft. Die auf den ersten Blick redundant erscheinende Datenhaltung für Kategorien unterscheidet sich tatsächlich in der Definition der Elternkategorie. Für die Beziehung zwischen Mediengruppe und Domäne sowie zwischen Mediengruppentyp und Domäne ist die Situation ähnlich. Etwas anders gestaltet sich die Situation für die Beziehung zwischen Schlagwort und Domäne. Das folgende Beispiel erläutert die gegebene Problematik näher. In Abbildung 8.4 ist die Ausgangssituation dargestellt. Bei Betrachtung der Tabellen kann nicht genau gesagt werden, welches Schlagwort zu welcher Kategorie innerhalb einer Domäne gehört: Möglicherweise soll das Schlagwort rot innerhalb der Domäne B nur für die Kategorie Birne eingesetzt werden. Das Datenmodell ist jedoch unzulänglich, da sich das Schlagwort rot innerhalb der Domäne B auch auf die Kategorie Apfel beziehen kann. Wie in Abbildung 8.5 dargestellt, muss sowohl für ein Schlagwort als auch für eine Kategorie die zugehörige Domäne gespeichert werden. Erst dadurch kann garantiert werden, dass ein Schlagwort eindeutig einer Domäne und einer Kategorie zuordenbar ist: Einmal ist ein Schlagwort rot (ID 5) der Kategorie Apfel innerhalb der Domäne A zugeordnet; ein anderes Mal ist ein Schlagwort rot (ID 6) der Kategorie Birne innerhalb der Domäne B zugeordnet. Der in Abbildung 8.5 vorgestellte Ansatz ermöglicht die eindeutige Abbildung von den folgenden Beziehungen: Kategorie und Domäne sowie Schlagwort und Domäne. Ferner kann ein Schlagwort eindeutig Kategorien zugeordnet werden. Dieser Ansatz kann ebenso für die Beziehung zwischen Mediengruppe und Domäne sowie zwischen Mediengruppentyp und Domäne übernommen werden. Aus diesem Grund wurde diese Abbildungsform für das Datenmodell gewählt.

40 8. Umsetzung 30 Abbildung 8.6: TEAPOT Core Architektur. 8.3 Architektur von TEAPOT Core In diesem Abschnitt wird die Architektur von TEAPOT Core näher betrachtet. Die einzelnen Bereiche werden unter anderem durch Klassendiagramme näher beschrieben Allgemein Abbildung 8.6 gibt einen Überblick über den detaillierten Aufbau von TEAPOT Core. Die Programmlogik wird in drei Schichten unterteilt (von unten nach oben): Business Objects, Data Acces Objects und Business Methods. Diese drei Schichten werden in den folgenden Abschnitten näher beschrieben Business Objects Ein Business Object implementiert keine speziellen Methoden. Es verfügt lediglich über Methoden zum Auslesen und Setzen von Eigenschaften (Setter und Getter). Aus diesem Grund können diese Objekte auch auf der Applikationsschicht verwendet werden. In Abbildung 8.7 auf der nächsten Seite wird das Klassendiagramm für das Paket teapot.businessobject von TEAPOT Core dargestellt. Die hier abgebildeten Klassen repräsentieren die Datentabellen des Datenmodells (siehe Abbildung 8.2 auf Seite 27). Die beiden Klassen AbstractBusinessObject und AbstractTimestampAbleBusinessObject bilden dabei eine Ausnahme. Durch die Ableitung von AbstractBusinessObject ist die Vergabe einer eindeutigen ID beim Erzeugen eines Objekts gegeben. Klassen, die von AbstractTimestampAbleBusinessObject ableiten, verfügen zusätzlich über einen Zeitstempel. Dieser kann unter anderem für die Einschränkung der Suchkriterien bei einer erweiterten Suche genutzt werden. Beide Klassen sind nicht als eigene Tabellen in dem Datenmodell vorhanden. Statt dessen sind je nach Basisklasse der Business Objects die Felder ID und optional auch das Feld Timestamp (Zeitstempel) verfügbar. Die Beziehungen der Klassen untereinander werden in Abbildung 8.8 auf Seite 32 dargestellt. Dabei wird auf die Darstellung von Vererbungen verzichtet. Auch Klassen, die in keiner Beziehung zu anderen Klassen stehen, werden in diesem Diagramm nicht abgebildet. Im Wesentlichen stellt Abbildung 8.8 auf Seite 32 jene Beziehungen dar, die bereits auf Ebene des Datenmodells beschrieben wurden (siehe Abschnitt 8.2).

41 8. Umsetzung 31 Abbildung 8.7: Klassendiagramm für das Paket teapot.businessobject.

42 8. Umsetzung 32 Abbildung 8.8: Beziehungen der Klassen zueinander Data Access Objects Die Data Access Objects enthalten die Operationen für die Lese- und Schreibzugriffe auf die Business Objects (siehe vorhergehenden Abschnitt). In Abbildung 8.9 auf der nächsten Seite wird das Klassendiagramm für das Paket teapot.dao von TEAPOT Core dargestellt. Dabei handelt es sich in diesem Fall um die Schnittstelle für die Data Access Objects. Die Implementierung dieser Schnittstelle befindet sich in dem Paket teapot.dao.impl von TEAPOT Core. Da jedes Data Access Object die gleichen Operationen enthält und diese bis auf den Typ gleich implementiert sind, wird in TEAPOT Core ein generisches Data Acces Object verwendet. Diese Data Access Object enthält einmalig die Schnittstelle bzw. die Implementierung für diese Schnittstelle. Dadurch wird eine Quellcodeverdoppelung vermieden. Beim Aufruf einer Methode aus dem generischen Data Access Object wir der Datentyp des Objekt mitgegeben, wodurch das mitgegebene Objekte passend für den Datentyp weiterverarbeitet wird. Es wird dennoch für jedes nicht abstrakte Business Object eine Data Access Object von dem generischen Data Access Object abgeleitet. Diese werden angeboten, falls spezifische Methoden benötigt werden Business Methods Die Business Methods repräsentieren die Programmierschnittstelle. Sie enthalten die gesamte Business-Logik und verwalten die Relationen zwischen den Objekten. Bei der Anwendungsimplementierung stehen sie dem Entwickler zur Umsetzung der Funktionalitäten zur Verfügung. In Abbildung 8.10 auf Seite 34 wird das Klassendiagramm für das Paket teapot.businessmethod von TEAPOT Core dargestellt. Dabei sind die Business Methods nach

43 8. Umsetzung 33 Abbildung 8.9: Klassendiagramm für das Paket teapot.dao. ihren Rückgabetypen in unterschiedlichen Klassen sortiert. Zum Beispiel werden alle Operationen, die Media Assets zurückliefern, in der Klasse AssetBusinessMethods zur Verfügung gestellt. Außerdem wird die Implementierung der Lese- und Schreibzugriffe für ein Media Asset in dieser Klasse verwaltet. Für die Implementierung dieser Operationen wird auf die Data Access Objects zurückgegriffen. Zusätzlich werden in diesen Operationen unter anderem notwendige Überprüfungen implementiert. Außerdem sind alle in diesem Paket angebotenen Methoden zustandslos. Das heißt sie sind als statische Methoden implementiert und von keinem Objekt abhängig. In der Klasse BusinessMethodHelper werden Hilfsfunktionen für die Überprüfung von Abhängigkeiten zwischen Objekte angeboten. Die Klasse SearchBusinessMethods enthält sämtliche Implementierungen für die Suchfunktion von TEAPOT. Die Suchfilter sind in der Klasse SearchFilters hinterlegt. Die Business Methods sind prinzipiell Teil der Data Access Objects. Für die bessere Übersicht sind sie von den Data Access Objects abgekapselt. Während die Business Methods dazu gedacht sind, dass auf sie von außen zugegriffen werden kann, scheinen die Data Access Objects nicht in der Programmierschnittstelle auf. Die Programmierschnittstelle leitet die Lese- und Schreibzugriffe an die Data Access Objects weiter, die dann die Datenbankzugriffe durchführen. Der Grund dafür ist, dass dadurch Datenbankzugriffe nur vom Server ausgeführt werden. Auf diese Weise fällt für die Entwicklung der Benutzeranwendung die Komplexität der Datenbankzugriffe weg. Die Bezeichnung Business Methods wurde in Anlehnung an die Business Objects ausgewählt. Dieser Teil von TEAPOT Core kümmert sich um die Verarbeitung der Objekte, während die Data Access Objects die Verwaltung der Objekte in der Datenbank übernehmen.

44 8. Umsetzung 34 Abbildung 8.10: Klassendiagramm für das Paket teapot.businessmethod.

45 Kapitel 9 Evaluierung Die wesentlichen Funktionalitäten von TEAPOT Core wurden mit verschiedenen Technologien implementiert: ibatis in Verbindung mit MySQL, ibatis in Verbindung mit PostgreSQL, Hibernate in Verbindung mit MySQL und Hibernate in Verbindung mit PostgreSQL. Um die am besten geeignete Kombination zu eruieren, wurden Tests mit Zeitmessungen durchgeführt. Dieses Kapitel beschäftigt sich mit der Evaluierung der durchgeführten Zeitmessungen. 9.1 Allgemeines Die Suche ist ein wichtiger Bestandteil des Media Asset Management Systems TEAPOT. Darum wurde insbesondere hierfür die Zeit gemessen. Des Weiteren ist die Suche einer der wenigen Punkte in dem Programm, wo Abfragen durch den Entwickler definiert werden. Im restlichen System übernimmt das objektrelationale Datenbankabbildungswerkzeug diese Aufgabe. Für die Zeitmessungen wurde je Kombination und je Datensatzanzahl ein Durchlauf von zehn Abfragen durchgeführt. Für die Grafiken wurde der Median der gemessenen Zeiten zur Hand genommen. Die genauen Ergebnisse der Zeitmessungen sind auf der DVD zu finden. Die Tests wurden so vorbereitet, dass die Testbedingungen (z. B. Zuordnung der Schlagwörter zu den Media Assets) jederzeit wieder hergestellt werden können. Mit einem Hilfswerkzeug wurden die in Abbildung 9.1 auf der nächsten Seite aufgeschlüsselten Datensätze erzeugt. Abbildung 9.2 auf der nächsten Seite zeigt die Formel zur Berechnung der ungefähren Datenmenge, die durch das Hilfswerkzeug erzeugt werden. Die Zeitmessungen wurden unter Windows XP auf einem MacBook Pro mit 2,33 GHz Intel Core 2 Duo und 2 GB Hauptspeicher durchgeführt. Natürlich wurden auf der Datenbank für alle Primär- und Fremdschlüssel Indizes angelegt. Vor dem Durchführen der Tests auf der PostgreSQL Datenbank wurden die Indizes reorganisiert und die Aktion Vakuum durchgeführt. 9.2 Einfache Suche Für die einfache Suche wird die Datenbankabfrage durch den Entwickler zusammengebaut. Dabei wird der eingegebene Suchbegriff in dem Namen, in der Beschreibung und in den Schlagwörtern eines Media Assets gesucht. In Abbildung 9.3 auf Seite 37 sind die Ergebnisse der Zeitmessung für die einfache Suche dargestellt. Der wesentliche Zeitunterschied ergibt sich aus der Wahl des Datenbankmanage- 35

46 9. Evaluierung 36 Abbildung 9.1: Aufschlüsselung der Anzahl der erzeugten Datensätze (ohne Berücksichtigung der Beziehungen). A D... Anzahl der Domänen A A... Anzahl der Media Assets A S... Anzahl der Schlagwörter A K... Anzahl der Kategorien A M... Anzahl der Mediengruppen A T... Anzahl der Mediengruppentypen Anzahl der Zeilen aller normalen Tabellen: A D + 6A A + 3A S + 3A K + 3A M + A T Maximale Anzahl der Zeilen in den Zwischentabellen: asset_keywords: 3A A (jedes Asset hat 3 Keywords) asset_categories: 2A A (jedes Asset hat 2 Kategorien) asset_mediagroups: 1A A (jedes Asset hat eine Mediagroup) category_keyword: 1A K (jede Category hat 0 bis 2 Keywords; Mittelwert = 1) mediagropup_keyword: 1A M (jede Mediagroup hat 0 bis 2 Keywords; Mittelwert = 1) Abbildung 9.2: Formel zur Berechnung der ungefähren Datenmengen. mentsystems. Das objektrelationale Datenbankabbildungswerkzeug spielt eine untergeordnete Rolle. Die blaue und die gelbe Linie repräsentieren in Abbildung 9.3 auf der nächsten Seite die Zeitdauer der Suchanfrage unter Verwendung des Datenbankmanagementsystems MySQL, während die rote und die grüne Linie die benötigte Zeit der Suchanfrage unter Verwendung des Datenbankmanagementsystems PostgreSQL angeben. Das Datenbankmanagementsystem MySQL ist bei der Abarbeitung der Suchanfrage wesentlich langsamer als das Datenbankmanagementsystem PostgreSQL. Des Weiteren fällt auf, dass der zeitliche Unterschied zwischen den Suchanfragen bei steigender Anzahl der Datensätze exponentiell zunimmt. Das Datenbankmanagementsystem MyS- QL benötigt bei ansteigender Anzahl der Datensätze verglichen zu dem Datenbankmanagementsystem PostgreSQL wesentlich mehr Zeit für die Abarbeitung der einfachen Suchanfrage.

47 9. Evaluierung 37 Abbildung 9.3: Ergebnis der Zeitmessung für die einfache Suche. 9.3 Suche nach einem Schlagwort Diese Suchanfrage wird für die Auswahl der Media Assets nach Schlagwörtern benötigt. Auch hier handelt es sich um eine Datenbankanfrage, die durch den Entwickler zusammengesetzt wird. Die einfache Abfrage mittels Aufruf der Methode keyword.getassets ist nicht ausreichend: Es sollen jene Media Assets zurückgeliefert werden, die entweder direkt, über eine Kategorie oder über eine Mediengruppe mit dem gesuchten Schlagwort verbunden sind. In Abbildung 9.4 auf der nächsten Seite sind die Ergebnisse der Zeitmessung für die Suche nach einem Schlagwort dargestellt. Das Ergebnis zeigt wie bei der einfachen Suche, dass der wesentliche Unterschied durch das eingesetzte Datenbankmanagementsystem und nicht durch das eingesetzte objektrelationale Datenbankabbildungswerkzeug verursacht wird. Die blaue und die gelbe Linie repräsentieren in Abbildung 9.4 auf der nächsten Seite die Zeitdauer der Suchanfrage unter Verwendung des Datenbankmanagementsystems MySQL, während die rote und die grüne Linie die benötigte Zeit der Suchanfrage unter Verwendung des Datenbankmanagementsystems PostgreSQL angeben. Auch hier ist das Datenbankmanagementsystem MySQL bei der Abarbeitung der Suchanfrage wesentlich langsamer als das Datenbankmanagementsystem PostgreSQL. Je höher die Anzahl der Datensätze in der Datenbank ist, desto größer wird der zeitliche Unterschied zwischen den Datenbankmanagementsystemen. Im Gegensatz zu Abbildung 9.3 ist auf Abbildung 9.4 auf der nächsten Seite zu erkennen, dass ibatis im Vergleich zu Hibernate etwas schneller ist. Dieser feine Unterschied kann jedoch außer Acht gelassen werden, da er nicht für alle Ergebnisse der Zeitmessung eindeutig ist. Bei geschätzten Datensätzen in der Datenbank ist Hibernate in Verbindung mit PostgreSQL in etwa ebenso schnell wie ibatis in Verbindung mit PostgreSQL.

48 9. Evaluierung 38 Abbildung 9.4: Ergebnis der Zeitmessung für die Suche nach einem Schlagwort. 9.4 Suche nach einer Kategorie Diese Suchanfrage wird für die Auswahl der Media Assets nach Kategorien benötigt. Im Gegensatz zu den beiden vorangehenden Suchabfragen wird diese Suchanfrage nicht durch den Entwickler zusammengesetzt. In diesem Fall ist die einfache Abfrage mittels Aufruf der Methode Category.getAssets ausreichend. Die Ergebnisse der Zeitmessung variieren stark und sind auf die Laufzeit des Programms zu beziehen. Es wird vermutet, dass hier das Befüllen der Arrays mit den Rückgabewerten der Abfrage den Großteil der gemessenen Zeit in Anspruch nimmt. Des Weiteren ist die Antwortzeit mit weniger als einer viertel Sekunde äußerst gering. Aus diesem Grund ist das Ergebnis der Zeitmessung in Abbildung 9.5 auf der nächsten Seite nicht aussagekräftig und für die Entscheidungsfindung irrelevant. Bei näherer Betrachtung von Abbildung 9.5 auf der nächsten Seite fällt auf, dass ibatis in Verbindung mit PostgreSQL (rote Linie) von den anderen Ergebnissen abweicht. Während die restlichen Zeitmessungsergebnisse mit kleinen zeitlichen Unterschieden parallel verlaufen, kreuzt das Ergebnis von ibatis in Verbindung mit PostgreSQL (rote Linie) die anderen Ergebnislinien. Ferner kann aus Abbildung 9.5 auf der nächsten Seite abgelesen werden, dass die abgesetzte Suchanfrage auf die Datenbank bei Datensätzen weniger Zeit in Anspruch nimmt als bei Datensätzen. Diese zeitlichen Unterschiede sind durch die unterschiedliche Anzahl der zurückgelieferten Media Assets begründet. Die Anzahl der Media Assets, die bei einer Suchanfrage zurückgeliefert werden, sind in Abbildung 9.6 auf der nächsten Seite dargestellt. 9.5 Suche nach einer Mediengruppe Diese Suchanfrage wird für die Auswahl der Media Assets nach Mediengruppen benötigt. Für diese Sucheanfrage gilt das Gleiche wie für die zuvor beschriebene Suchanfrage: Sie muss

49 9. Evaluierung 39 Abbildung 9.5: Ergebnis der Zeitmessung für die Suche nach einer Kategorie. Abbildung 9.6: Anzahl der gefunden Media Assets für die Suchanfrage. nicht durch den Entwickler zusammengesetzt werden. Die einfache Abfrage mittels Aufruf der Methode Mediagroup.getAssets ist ausreichend. Die Ergebnisse der Zeitmessung variieren ebenso und sind mehr auf die Laufzeit des Programms zu beziehen. Es wird vermutet, dass hier ebenfalls das Befüllen der Arrays mit den Rückgabewerten der Abfrage den Großteil der gemessenen Zeit in Anspruch nimmt. Aus diesem Grund ist das Ergebnis der Zeitmessung in Abbildung 9.7 auf der nächsten Seite nicht aussagekräftig und für die Entscheidungsfindung irrelevant. Ebenso wie in Abbildung 9.5 fällt auch in Abbildung 9.7 auf der nächsten Seite auf, dass ibatis in Verbindung mit PostgreSQL (rote Linie) ein ungleichmäßiges Zeitmessungsergebnis aufweist. Während die anderen Linien mit einem kleinen zeitlichen Unterschied parallel verlaufen, quert die rote Linie diese teilweise. Auch hier werden in Abbildung 9.8 auf der nächsten Seite zur besseren Interpretation der Zeitmessungsergebnisse die Anzahl der gefunden Assets dargestellt.

50 9. Evaluierung 40 Abbildung 9.7: Ergebnis der Zeitmessung für die Suche nach einer Mediengruppe. Abbildung 9.8: Anzahl der gefunden Media Assets für die Suchanfrage. 9.6 Interpretation der Ergebnisse der Zeitmessungen Das Ergebnis der durchgeführten Zeitmessungen zeigt auf, dass die wesentlichen zeitlichen Unterschiede durch die Wahl des Datenbankmanagementsystems bestimmt ist. Bei den objektrelationalen Datenbankabbildungswerkzeugen sind die zeitlichen Unterschiede viel geringer und daher auch unbedeutend. Die Unterschiede der eingesetzten Technologien sind in Kapitel 6 in diesem Teil näher erläutert. Aufgrund der Ergebnisse der Zeitmessung wird hier keines der beiden objektrelationalen Datenbankabbildungswerkzeuge empfohlen. Der Entwickler hat die Freiheit jenes Werkzeug zu wählen, das er persönlich bevorzugt. Der Vorteil von ibatis ist, dass der Entwickler mehr Kontrolle über die abgesetzten Abfragen hat, da diese selbst definiert werden müssen. Daraus ergibt sich der Nachteil eines erhöhten Arbeitaufwands. Hibernate ist im Vergleich zu ibatis ein mächtigeres Werkzeug. Der Entwickler muss

51 9. Evaluierung 41 sich über die Erstellung der Datenbankabfragen weniger Gedanken machen, da die Abfragen von Hibernate generiert werden. Dadurch ist jedoch die Kontrolle über die abzusetzenden Datenbankabfragen eingeschränkt. Bei den Datenbankmanagementsystemen entsteht aufgrund der Ergebnisse der Zeitmessung eine eindeutige Präferenz: PostgreSQL. Dieses Datenbankmanagementsystem kann zum einen durch die hohe Geschwindigkeit punkten. Zum anderen bietet PostgreSQL mehr Funktionen an, die zu einer Geschwindigkeitssteigerung bei Datenbankabfragen beitragen können. Bei MySQL könnte eine Steigerung der Geschwindigkeit durch den Einsatz des Treibers MyISAM an Stelle des Treibers InnoDB erreicht werden. Da durch den Treiber MyISAM jedoch keine Fremdschlüssel unterstützt werden, wäre die Konsistenz der Datenbank nicht mehr gewährleistet. Die Konsistenz der Daten sollte nicht unter einer möglichen Geschwindigkeitssteigerung leiden. Deshalb ist das Datenbankmanagementsystem PostgreSQL für TEAPOT am besten geeignet.

52 Kapitel 10 Stand der Technik (Benutzeroberfläche) Die für TEAPOT entworfene Benutzeroberfläche ist für die Verwaltung von Media Assets vorgesehen. Mit Hilfe dieser Benutzeroberfläche können einzelne oder mehrere Media Assets in das System eingespielt oder aus dem System heruntergeladen werden. Des Weiteren wird die Sortierung der Media Assets durch unterschiedliche Strukturen, wie zum Beispiel Kategorien oder Schlüsselwörter, unterstützt. In dem System können Media Assets durch das Durchsuchen der Strukturen oder durch die gezielte Suche gefunden werden. Bei der gezielten Suche wird zwischen einer einfachen Schlagwortsuche und einer erweiterten Suche unterschieden. Die erweiterte Suche berücksichtigt die Metadaten und den Dateityp der Media Assets. TEAPOT ist in dieser Form für den internen Gebrauch in Firmen oder für den Einsatz in Projektteams gedacht. Aus diesem Grund werden folgend Benutzerschnittstellen anderer Media Asset Management Systeme analysiert. Systeme, die wie TEAPOT der Verwaltung von Media Assets dienen, sind beispielsweise AssetBank 1, Celum 2 und Fluxiom 3. Die Benutzeroberflächen dieser drei Webapplikationen unterscheiden sich stark von einander. AssetBank präsentiert sich als eine herkömmliche Webseite und verzichtet auf den Einsatz neuer Technologien (z. B. Ajax). Im Gegensatz dazu erzeugt Fluxiom mit Hilfe von Ajax die Illusion eines Desktoperlebnisses im Internet. Die Benutzeroberfläche von Celum ähnelt einer Desktopapplikation unter Windows. Trotz ungleicher Benutzeroberflächen unterstützen alle drei Systeme die Sortierung von Media Assets durch verschiedene Strukturen. Des Weiteren wird von diesen Systemen eine einfache und erweiterte Suche nach Media Assets angeboten. Celum bietet dabei die mit Abstand umfangreichste Suche an. Neben detaillierten Suchangaben hinsichtlich der Metadaten von Media Assets kann unter anderem für die Bildersuche eine dominant vorkommende Farbe angegeben werden. In der Verwaltung von Media Assets mit Hilfe von Strukturen ist Fluxiom das schwächste System. Während AssetBank und Celum eine umfangreiche Kategorisierung und Beschlagwortung der Media Assets erlauben, bietet Fluxiom lediglich eine Strukturierung mittels Schlagworten (englisch: tags) an. Die von Fluxiom gewählte Bezeichnung Schlagwort ist dabei jedoch irreführend; treffender wäre die Wortwahl Kategorie gewesen. Denn Fluxiom weist selbst dar

53 10. Stand der Technik (Benutzeroberfläche) 43 Abbildung 10.1: Fluxiom. auf hin, dass die Schlagworte sparsam eingesetzt werden sollen [3]: Tip: Use tags sparingly! You can still add freeform tags to every asset e.g. in the description field to help fluxiom shoot straighter when searching for assets. Werden bei Fluxiom sehr viele Schlagworte eingesetzt wird dadurch die Anzeigefläche für die Media Assets stark verkleinert (siehe Abbildung 10.1). Für die Beschlagwortung mit beliebig vielen Schlagworten wird auf das Beschreibungsfeld eines Media Assets verwiesen. Weitere Unterschiede zwischen diesen Systemen sind der Auflistung (siehe Abbildung 10.4 auf Seite 47) zu entnehmen. Die für TEAPOT entworfene Benutzeroberfläche zur Verwaltung von Media Assets ist nur eine Einsatzmöglichkeit. Unter anderem kann TEAPOT auch als Lösung für eine virtuelle Gemeinschaft 4 mit Interessenschwerpunkt Fotografie, Film, Computergrafik und Musik angeboten werden. Daher werden folgend Lösungen mit dem Interessenschwerpunkt Fotografie und Film näher betrachtet. Bekannte Plattformen für virtuelle Gemeinschaften dieser Art sind Flickr 5 und Google Picasa 6. Neben der Verwaltung der eigenen Bilder mit Hilfe von Alben und Schlagworten, ist für diese beiden Systeme die Kommunikation mit anderen Mitgliedern der Gemeinschaft vordergründig. Die Kommentarfunktion für Bilder ist ebenso Standard, wie 4 Unter einer virtuellen Gemeinschaft wird zumeist eine Plattform im Internet verstanden, auf der sich Menschen mit gleichen Interessen elektronisch austauschen und unterhalten können [6, Seite 4]

54 10. Stand der Technik (Benutzeroberfläche) 44 das Verlinken von Bildern auf einer Weltkarte. Des Weiteren unterstützen beide Plattformen das Sammeln von favorisierten Bildern. Auf diese Weise kann man immer wieder zu seinen Lieblingsfotos bei anderen Mitgliedern zurückfinden. Flickr forciert die virtuelle Gemeinschaft allerdings stärker als Picasa. Es können Gruppen gebildet werden, in der Mitglieder zu einem vorgegebenen Thema Fotos austauschen und diskutieren können. Wie zuvor angedeutet wird von beiden Plattformen nur das Speichern von Bildern und Videos unterstützt. Dabei können Videos unter Flickr nur gegen ein monatliches Entgelt eingespielt werden. Weitere Unterschiede zwischen den hier betrachteten Systemen sind der Abbildung 10.4 auf Seite 47 zu entnehmen. Eine weitere Möglichkeit für die Nutzung von TEAPOT ist die Verkaufsplattform für Media Assets. Zu den Systemen im Internet, die eine ähnliche Leistung erbringen, zählen die Marktführer Corbis 7 und GettyImages 8. GettyImage setzt im Hintergrund das Media Asset Mangement System Artesia 9 ein. Auf den Startseiten beider Verkaufsplattformen ist ein Suchfeld zu finden. In dieses Suchfeld wird ein Schlagwort eingegeben. Nach Absetzen der Suchanfrage werden die gefundenen Media Assets auf einer Ergebnisseite angezeigt. Bei alltäglichen Suchbegriffen besteht das Suchresultat zumeist aus sehr vielen Media Assets. Um die Anzahl der gefundenen Media Assets weiter zu reduzieren kann die Suche nachträglich eingeschränkt werden. Des Weiteren werden die Kategorien und Schlagworte zu den gefundenen Media Assets ausgegeben. Durch deren Einschränkung kann ebenso die Anzahl der gefundenen Media Assets reduziert werden. Eine weitere Funktion, die von beiden Verkaufsplattformen unterstützt wird, ist die Suche nach ähnlichen Bildern. Dabei werden die gesamten Schlagworte eines Media Assets sortiert nach Themengebieten angezeigt. Der Benutzer wählt darunter jene Schlagworte aus, die bei der Suche nach ähnlichen Bildern berücksichtigt werden sollen. Beim Durchsehen der Schlagworte entsteht der Eindruck, dass für beide Plattformen Quantität vor Qualität kommt. In der großen Menge an Schlagworten ist es öfters der Fall, dass ein Schlagwort zum Beispiel als Einzahl- und Mehrzahlwort vorhanden ist. Dabei sollten derart ähnliche Schlagwörter als ein Schlagwort gelten um bessere Suchergebnisse zu erzielen. Neben dem zentralen Aspekt der Suche spielt für die beiden Verkaufsplattformen auch der optische Reiz eine wichtige Rolle. Die Kunden sollen durch die Präsentation und die Qualität der Bilder in den Bann gezogen werden. Dadurch heben sich die Verkaufsplattformen auch von virtuellen Gemeinschaften mit Interessenschwerpunkt Fotografie ab. Insgesamt betrachtet bietet GettyImages mehr Auswahl als Corbis. GettyImages verkauft nicht nur Bilder, sondern auch Videos und Musik. Corbis bietet dagegen nur Bilder und Videos an, wofür zwei unterschiedliche Webseiten benutzt werden. Weitere Unterschiede der beiden Verkaufsplattformen werden in Abbildung 10.4 auf Seite 47 präsentiert

55 10. Stand der Technik (Benutzeroberfläche) 45 Abbildung 10.2: Flickr.

56 10. Stand der Technik (Benutzeroberfläche) 46 Abbildung 10.3: GettyImages.

57 10. Stand der Technik (Benutzeroberfläche) 47 Abbildung 10.4: Vergleich von Media Asset Management Systemen.

58 Kapitel 11 Plädoyer für ein besseres Design In die Entwicklung der Benutzeroberfläche wird zumeist zu wenig Zeit investiert. Dies ist ein großer Fehler in der Entwicklung, da der Benutzer ein Programm nicht nur nach den angebotenen Funktionalitäten sondern auch anhand der Benutzeroberfläche beurteilt. Die Benutzeroberfläche ist folgich mindestens ebenso wichtig wie die dahinter stehende Programmlogik und Funktionsvielfalt. Aus diesem Grund lohnt es sich der Gestaltung der Benutzeroberfläche mehr Aufmerksamkeit zu schenken und an einem durchdachtem Design zu arbeiten. Es stellt sich daher zu Beginn die Frage, was unter durchdachtem Design verstanden werden kann. Eine weitere daraus resultierende Frage ist, wodurch sich eine gut gestaltete Benutzeroberfläche auszeichnet. Auf diese Fragen gibt es Antworten in Form von Gestaltungsregeln, Standards oder Heuristiken. Diese geben jedoch keine Antwort darauf, was fernab dieser Richtlinien darüber entscheidet, ob ein Designkonzept erfolgreich oder erfolglos ist. Dem nachstehenden Gedanke zu Folge ist dieser feine Unterschied schwer in Worte zu fassen. Die Qualität eines großartigen Designs ist schwer in Worte zu fassen. Meist werden nur Teilaspekte des Designs betrachtet, nicht aber das Problem in seiner Gesamtheit. Gutes Aussehen und guter Inhalt sind wichtig, aber es gibt eine tiefschürfendere Faszination [11, Seite 3]: There is a quality about a great design that is difficult to put into words. It s always tempting to focus on just a few aspects of a design, separate from the whole problem. Good looks, good flow, good content all those things are important, but how do you pin down that feeling of satisfaction you get when you encounter a tool or toy that cliks with you on a deep level? Marc Rettig (1996) Dieser Abschnitt wird dennoch versuchen eine Antwort auf die Frage nach diesem feinen Unterschied zu geben. Wenngleich daraus mit Sicherheit kein Patentrezept für die Entwicklung eines erfolgreichen und durchdachten Designs entstehen wird. Viel mehr geht es darum, in dieser Antwort eine Motivation für das Streben nach durchdachtem Design zu geben. Neben der Einhaltung von bekannten Richtlinien zeichnet eine durchdacht gestaltete Benutzeroberfläche aus, dass sie den Bedürfnissen des Benutzers entgegenkommt und seine Erwartungen erfüllt. Darüber hinaus sollte das Design in seiner Gesamtheit (Anordnung der gestalterischen Elemente, Komposition der Farben etc.) den Benutzer ansprechen und emotional involvieren. Gerade die emotionale Komponente ist bei der Bewertung von Design nicht zu unterschätzen [22, Seite 15]: 48

59 11. Plädoyer für ein besseres Design 49 Design ist oftmals keine rationale Angelegenheit, sondern eine Frage des Gefühls. Gutes Design überzeugt emotional. Dieser Meinung schließt sich auch Joel Spolsky an, der den Designprozess einer Benutzeroberfläche mit den Augen eines Programmierers betrachtet. Die Benutzeroberfläche ist wichtig, weil sie die Emotionen des Benutzers beeinflusst. Gut gestaltete Benutzeroberflächen machen den Benutzer glücklich, während schlecht gestaltete Benutzeroberflächen dem Benutzer ein Gefühl der Ohnmacht geben [20, Seite 6]: UI is important because it affects the feelings, the emotions, and the mood of your users. If the UI is wrong and the user feels like they can t control your software, they literally won t be happy and they ll blame it on your software. If the UI is smart and things work the way the user expected them to work, they will be cheerful as they manage to accomplish small goals. Hey! I ripped a CD! It just worked! Nice software!! In dem vorangegangenen Gedanken findet sich auch das erste Argument, welches für gut gestaltete Benutzeroberflächen spricht. Es ist die marktwirtschaftliche Motivation einen zufriedenen Endanwender zu haben und ihn dadurch an ein Produkt zu binden. Gerade auf dem heutigen Markt, auf dem viele gleichwertige Produkte angeboten werden, ist gutes Design eine der wenigen Möglichkeiten sich von der Konkurrenz abzuheben [22, Seite 13]: Im Bereich der Computer und Software wird das Design der Benutzer-Schnittstelle immer wichtiger, weil die Branche ihre wilden Anfangsjahre langsam hinter sich lässt. Es gibt ein halbes Dutzend funktionell gleichwertiger Programme zur Textverarbeitung auf dem Markt. Da ist derjenige Anbieter im Vorteil, derq mit einer leicht zu bedienenden und verständlichen Bedienoberfläche überzeugen kann. Es wäre nun zu leicht davon auszugehen, dass es nicht mehr benötigt, als einfach ein gut durchdachtes Design. Die Aufgabe der Designentwicklung sollte nicht unterschätzt werden. Um sie zu bewältigen braucht es viel Energie, Wissen und Fingerspitzengefühl. Die Mühen werden letztlich aber durch einen zufriedenen Endanwender belohnt [22, Seite 14]: Das Interface-Design ist also eine Aufgabe, die nicht leicht zu lösen sein wird. Sie erfordert besondere Überlegungen im Entwicklungsprozess. Trotzdem lohnt es sich, viel Arbeit gerade in diesen Bereich der Applikation zu stecken. Denn mit einer gut entworfenen grafischen Oberfläche kann ein Anbieter im Markt Punkte sammeln und die Kunden überzeugen. Bereits zuvor ist die Sprache auf den Benutzer gekommen. Er spielt eine zentrale Rolle in der Entwicklung eines durchdachten Designs. Denn für ihn alleine wird die Benutzeroberfläche entworfen. Er wird das Produkt später verwenden und er soll damit zufrieden sein. Neben marktwirtschaftlichen Motiven ist der Benutzer die größte Motivation für das Streben nach gutem Design. Aus diesem Grund sollte der Benutzer maßgeblich für die Entscheidungen im Designprozess sein [22, Seite 14]: Beim Design aller Schnittstellen, die für menschliche Benutzer gedacht sind, müssen immer die spezifischen Eigenschaften des Menschen, des Homo Erectus, im Auge behalten werden. Das Werk kann nur gelingen, wenn die Bedürfnisse, Stärken und Schwächen dieses Wesens berücksichtigt werden.

60 11. Plädoyer für ein besseres Design 50 Das Produkt wird für den Benutzer gemacht. Daher muss das Produkt, in diesem speziellen Fall ein Programm, dem Benutzer entgegenkommen und seine Erwartungen erfüllen. Die Aufgabe des Benutzers besteht darin, seine Arbeit mit Hilfe der Software leichter zu erledigen. Der Benutzer darf nie in die Verlegenheit gebracht werden, dass er sich den Unzulänglichkeiten eines Programms anpassen muss [22, Seite 29]: Eines sollten wir dabei allerdings niemals vergessen: Es ist der Mensch, der hinter dem Lenkrad sitzt. Er sollte die Kontrolle haben und nicht die Maschine. Die Technik muss sich den Eigenschaften, den Stärken und Schwächen des Menschen anpassen und nicht umgekehrt. Neben marktwirtschaftlicher Motive und dem Benutzer gibt es eine weitere Motivation für das Streben nach gutem Design. Es gibt viele schlecht gestaltete Benutzeroberflächen, die den Bedürfnissen des Anwenders nicht entgegenkommen. Dies sollte als Motivation dafür dienen, mehr über Design und Benutzeroberflächen nachzudenken und es dadurch besser zu machen als andere. Indem man anfängt dem Design von Benutzeroberflächen mehr Aufmerksamkeit zu schenken, kann der Vermehrung von unzulänglichen Benutzeroberflächen entgegenwirkt werden. Es muss ins Bewusstsein gerufen werden, dass durchdachtes Design zum guten Ton gehört. Dennoch darf nicht erwartet werden, dass ein perfektes und makelloses Design erstellt werden kann. Es wird immer wieder notwendig sein Kompromisse während des Designprozesses zu schließen, weil es mit hoher Wahrscheinlichkeit widersprüchliche Anforderungen an das Design gibt. Trotzdem sollte man nie aufhören sich der Perfektion anzunähern, da nur so ein bestmögliches Ergebnis garantiert werden kann.

61 Kapitel 12 Benutzerfreundlichkeit Zunächst wird in diesem Abschnitt der Begriff der Benutzerfreundlichkeit erklärt. Anschließend werden die grundlegenden Heuristiken der Benutzerfreundlichkeit beschrieben Begriffserklärung Nach Jakob Nielsen ist Benutzerfreundlichkeit ein vielschichtiger Begriff. Er umschreibt nicht eine eindimensionale Eigenschaft einer Benutzeroberfläche, sondern unterschiedliche Komponenten. Zu diesen Komponenten zählen die nachstehend beschriebenen Merkmale [15, Seite 26]. Erlernbarkeit Ein Programm soll leicht zu erlernen sein, sodass der Benutzer rasch damit anfangen kann Aufgaben mit dem System zu erledigen. Produktivität Nach Erlernen des Programms soll es dem Benutzer möglich sein, Aufgaben möglichst schnell zu bewältigen. Das heißt, es soll ein hohes Level an Produktivität erreicht werden können. Einprägsamkeit Auch bei unregelmäßiger Benutzung des Programms soll der Benutzer es ohne erneutes Erlernen für seine Aufgaben einsetzten können (siehe auch Reduzierung der Gedächtnisleistung (Minimize User Memory Load)). Geringe Fehlerrate Der Benutzer soll während der Verwendung des Programms kaum Fehler machen können (siehe auch Fehlervermeidung (Prevent Errors)). Wenn dem Benutzer dennoch ein Fehler unterläuft, soll die Fehlersituation ohne Probleme zu verlassen werden können. (siehe auch Unterstützung bei der Entdeckung, Interpretation und Behebung von Fehlern (Good Error Messages)). Zufriedenheit Das Programm soll angenehm zu verwenden sein, sodass der Benutzer subjektiv zufrieden damit ist Heuristiken Unter dem Begriff Heuristik versteht man die Lehre von der Auffindung wissenschaftlicher Erkenntnisse auf methodischem Weg. Der folgende Abschnitt beschreibt die Heuristiken nach 51

62 12. Benutzerfreundlichkeit 52 Jakob Nielsen [15, Seite 115f], welche für den Entwurf einer benutzerfreundlichen Oberfläche unerlässlich sind Ästhetisches und minimalistisches Design (Simple and Natural Dialogue) Das Wichtigste bei dem Design einer Benutzeroberfläche sind immer die Bedürfnisse bzw. die Ansprüche des Benutzers. Die Benutzeroberfläche sollte sich dem Benutzer anpassen, nie der Benutzer der Benutzeroberfläche [20, Seite 8]: A user interface is well designed when the program behaves exactly how the user thought it would. Another way of saying this is: A user interface is well designed when the program model conforms to the user model. Eine Benutzeroberfläche soll außerdem einfach gehalten werden, da unnötige Informationen die Bedienung für den Benutzer anstrengender machen. Der Benutzer soll stets nur jene Informationen auf der Benutzeroberfläche angeboten bekommen, die er gerade benötigt. An dieser Stelle ist anzumerken, dass leere Flächen auf der Benutzeroberfläche in Ordnung sind. Es muss nicht jeder freie Platz mit Informationen oder Grafiken gefüllt werden. Weniger ist oft mehr. Des Weiteren ist eine klare Strukturierung der Inhalte notwendig. Dem Benutzer sollen Inhalte, die in Zusammenhang stehen, räumlich zusammenhängend angezeigt werden. Eine weitere Möglichkeit die Zusammengehörigkeit von Inhalten anzuzeigen ist die farbliche Codierung. Da es viele Menschen gibt, die farbenblind sind, sollte diese Möglichkeit jedoch nie alleine zum Einsatz kommen Kongruenz von System und realer Welt (Speak the Users Language) Die Sprache ist Teil der Gestaltung der Benutzeroberfläche. Aus diesem Grund sollte sich die Sprache an den Benutzer anpassen. Systembezogene Begriffe sollten durch Begriffe und Konzepte, die dem Benutzer vertraut sind, ersetzt werden. Ferner sind nationale und kulturelle Unterschiede bei der Benutzeroberflächengestaltung zu beachten. In einem für Amerikaner entworfenen Programm wäre die Wahl der Währung Euro beispielsweise fehl am Platz. Dabei beschränkt sich die Auswirkung nationaler und kultureller Unterschiede nicht auf Wort und Text. Auch bei der Gestaltung von Piktogrammen sind diese Besonderheiten zu berücksichtigen. Im dänischen Radio ist es beispielsweise üblich, dass zwischen zwei Sendungen anstelle von Werbung mehrmals hintereinander eine kurze Melodie als Zeitfüller gespielt wird. Daher wäre die Wahl des Pausezeichens für verzögerte Systemrückmeldung in Dänemark passend. In einem Land, wo zwischen zwei Radiosendungen Werbung gespielt wird, würde das Symbol missverstanden werden Reduzierung der Gedächtnisleistung (Minimize User Memory Load) Der Computer sollte dem Benutzer die Aufgabe abnehmen, sich Dinge merken zu müssen. Das Ziel ist es, dass sich der Anwender so wenig Informationen wie möglich in Erinnerung rufen muss. Der Anwender sollte seine ganze Aufmerksamkeit der eigentlichen Aufgabe widmen, die er mit Hilfe des Systems bewältigen möchte. Sollte es notwendig sein, dass der Benutzer

63 12. Benutzerfreundlichkeit 53 weitere Informationen über das System benötigt, so sollten diese sichtbar oder leicht abrufbar sein. Auch Joel Spolsky setzt sich mit dieser Thematik auseinander (People Can t Remember, [20, Seite 75ff]). Er beschreibt in seinem Buch, dass es leichter ist sich an etwas zu erinnern, wenn man Gedächtnisstützen erhält. So fällt es einem Anwender beispielsweise leichter sich an einen Dateinamen zu erinnern, wenn er diesen aus einer Auflistung auswählen kann Konsistenz und Standardkonformität (Consistency) Innerhalb eines Systems sollten folgende Komponenten konsistent sein: Screendesign, Terminologie und Funktionen. Für die Komponente Screendesign bedeutet dies beispielsweise, dass die Seitenkennung innerhalb eines Webauftritts immer an der gleichen Stelle platziert ist. Jedoch sollte Konsistenz nicht nur innerhalb eines Systems gegeben sein. Das System sollte sich auch zu anderen Systemen konsistent verhalten. Ein Anwender erwartet zum Beispiel, dass das Logo auf einer Webseite angeklickt werden kann und ihn dies zurück zu der Startseite führt. Bietet ein Webauftritt diese Funktionalität nicht, so verhält sich das System zu anderen Systemen inkonsistent. Im Bereich der Desktopanwendungen ist es wichtig, dass eine Anwendung die Standards des Betriebsystems berücksichtigt. Dazu zählt unter anderem die Beschriftung der Schaltflächen in einem Dialogfenster. Es entspricht dem Prinzip der Benutzerfreundlichkeit, wenn Schaltflächen in einer Dialogbox mit der gewohnten Beschriftung versehen sind. Eine nicht standardkonforme Beschriftung der Schaltflächen kann den Anwender verwirren und Ursache für Fehler sein. Joel Spolsky behandelt diese Thematik ausführlicher (Consistency and Other Hobgoblins, [20, Seite 43ff]) und kommt zu dem Schluss, dass Konsistenz in der Benutzeroberflächgestaltung wichtiger ist als das Ausleben von Kreativität [20, Seite 48]: Good UI designers use consistency intellegently, and though it may not show off their creativity as well, in the long run it makes users happier. Gute Benutzeroberflächengestalter achten auf Konsistenz in ihrem Design. Auf diese Weise ist es ihnen zwar nicht möglich ihre Kreativität unter Beweis zu stellen, aber langfristig gesehen ist der Benutzer mit der Benutzeroberfläche glücklicher Transparenz des Systemzustandes (Feedback) Für den Benutzer ist es wichtig Feedback über den aktuellen Systemzustand zu erhalten. Dabei sollten sich die Rückmeldungen nicht auf Fehlersituationen beschränken. Das System sollte dem Benutzer auch positives Feedback geben. Eine Beispiel für eine positive Rückmeldung ist die Bestätigung eines -Programms, dass eine Nachricht erfolgreich versandt wurde. Es ist nicht nur wichtig, dass der Benutzer durch zeitnahe Rückmeldungen über den aktuellen Systemzustand informiert wird, sondern auch in welcher Form er diese Informationen erhält. Wenn der Benutzer beispielsweise ein Verzeichnis mit einem großen Datenvolumen auf seinem Computer an eine andere Stelle verschieben möchte, so wird diese Aktion vermutlich länger als zehn Sekunden in Anspruch nehmen. Im Idealfall gibt das System in einem Dialog darüber Auskunft, welches Verzeichnis gerade verschoben wird und wie viel Zeit diese Aktion beanspruchen wird. Kann das System nicht vorhersagen, wie lange die Aktion dauern wird, so sollte in Form eine Ladebalkens über den Fortschritt der Aktion informiert werden. Für den

64 12. Benutzerfreundlichkeit 54 Anwender ist so ersichtlich, dass das System weiterhin an dieser Aktion arbeitet und nicht abgestürzt ist. Im Zusammenhang mit Systemrückmeldungen trifft Joel Spolsky eine passende Aussage, dass Sekunden wie Stunden sind [20, Seite 107]: Seconds Are Hours In diesem Abschnitt seines Buches erklärt Joel Spolsky das Zeitempfinden des Benutzers und gibt zugleich Ratschläge, wie man dem Benutzer das Gefühl einer geringen Systemantwortzeit vortäuschen kann Handlungskontrolle und -spielraum des Anwenders (Clearly Marked Exits) Wenn der Anwender irrtümlich eine Systemfunktion ausgelöst hat, soll er stets die Möglichkeit haben aus dieser Situation ohne Schaden wieder hinauszukommen. Zum einen kann dies durch einen Dialog geschehen, in dem der Anwender die Aktion abbrechen kann. Zum anderen können dies Funktionen sein, mit denen man Aktionen rückgängig machen (Undo-Funktion) oder aber auch Aktionen wiederholen kann (Redo-Funktion). Dabei ist es wichtig, dass diese Möglichkeiten für den Anwender deutlich sichtbar oder leicht auffindbar sind. Das Gefühl dem Computer nicht unterlegen zu sein, ermutigt den Anwender Funktionen auszuprobieren. Durch die Probierfreudigkeit wird das erforschende Lernen gefördert Flexibilität und Effizienz der Anwendung (Shortcuts) Eine Anwendung sollte einerseits unerfahrenen Benutzern eine einfache Interaktion ermöglichen. Andererseits sollte die Anwendung erfahrene Benutzer durch Tastaturkürzel und andere Abkürzungen, wie zum Beispiel ein Kontextmenü oder eine Protokollfunktion, in der Interaktion unterstützen. Die Möglichkeiten für den erfahrenen Benutzer sollten dem unerfahrenen Benutzer verborgen bleiben, um diesen nicht zu überfordern. Bei der Festlegung von Tastaturkürzeln für eine Anwendung ist darauf zu achten, dass Standardkürzel nicht durch eine andere Funktion überschrieben werden. Für den Anwender ist es ärgerlich, wenn er unter Windows die Tastenkombination Steuerung und S drückt und dabei nicht die erwartete Funktion, in diesem Fall das Speichern einer Datei, ausgeführt wird Unterstützung bei der Entdeckung, Interpretation und Behebung von Fehlern (Good Error Messages) Gelangt ein Anwender in eine Fehlersituation, bedeutet dies, dass er vor einem Problem steht und mit dem System im Moment nicht sein gewünschtes Ziel erreichen kann. An diesem Punkt sollte der Computer den Anwender mit Fehlermeldungen unterstützen. Damit es dem Anwender möglich ist Fehlermeldungen richtig zu interpretieren, sollten die folgenden vier Regeln für die Gestaltung von Fehlermeldungen befolgt werden [18, Seite 73f]: Fehlermeldungen sollten verständlich und selbsterklärend formuliert werden. Es sollten dem Anwender keine Fehlercodes ausgegeben werden, für dessen Identifizierung er ein Handbuch oder eine Dokumentation zu Rate ziehen muss.

65 12. Benutzerfreundlichkeit 55 Eine Fehlermeldung sollte das aufgetretene Problem so genau wie möglich beschreiben. Eine Meldung, die dem Benutzer mitteilt, dass irgendein Dokument nicht geöffnet werden kann, ist wenig hilfreich. Besser ist es, wenn in der Fehlermeldung angeführt wird, welches Dokument nicht geöffnet werden kann und aus welchem Grund dies nicht möglich ist. In der Fehlermeldung sollte dem Anwender ein konstruktiver Lösungsvorschlag für das aufgetretene Problem gemacht werden. Wenn eine Anwendung zum Beispiel eine Datei nicht öffnen kann, könnten alternative Programme zum Öffnen der Datei vorgeschlagen werden. Zuletzt sollte auf eine höfliche Formulierung der Fehlermeldungen geachtet werden. Um dies zu erreichen sollte für Fehlermeldungen keinesfalls durchgängige Großschreibung benutzt werden; dies kommt einem Anschreien gleich. Des Weiteren sollte auf Ausdrücke wie illegal oder fatal verzichtet werden. Der Benutzer sollte auf keinen Fall das Gefühl bekommen, dass er an dem aufgetretenen Problem Schuld hat. Wenn es um Fehlermeldungen geht, zeigen Benutzer eine hohe Bereitschaft diese Meldungen zu lesen. Sie hoffen darauf, dass ihnen die Fehlermeldung dabei hilft, ihr Problem zu lösen. Um dennoch sehr lange Fehlermeldungen zu vermeiden, kann zunächst nur eine kurze Variante der Meldung ausgeben werden, wobei die Möglichkeit besteht in eine detaillierte Ansicht zu wechseln Fehlervermeidung (Prevent Errors) Besser als dem Anwender hilfreiche Fehlermeldungen anzubieten, ist es die Entstehung von Fehlern durch eine sorgfältige Gestaltung zu vermeiden. Möglichkeiten zur Fehlervermeidung liegen unter anderem in der Ausschaltung fehleranfälliger Situationen. Solche Situationen können beispielsweise durch die Protokollierung auftretender Fehler identifiziert werden. Des Weiteren können Fehler durch die Prüfung und die explizite Bestätigung potentiell fehlerträchtiger Aktionen abgefangen werden. So sollte der Benutzer vor dem endgültigen Löschen einer Datei durch einen Dialog darauf hingewiesen werden, dass dies eine unwiderrufliche Aktion ist. Allerdings sollten Warnung dieser Art nicht überstrapaziert werden, da ihnen der Benutzer sonst nach einiger Zeit keine Aufmerksamkeit mehr schenkt und sie ohne Lesen bestätigt Hilfe und Dokumentation (Help and Documentation) Es ist ein wünschenswertes Ziel, dass ein System so einfach in der Bedienung ist, dass es ohne ein Hilfesystem, ein Handbuch oder eine Dokumentation auskommt. Dieses Ziel wird jedoch in der Realität nicht immer erreichbar sein. Deshalb ist es notwendig, dass für ein System auf jeden Fall ein Handbuch oder ein Hilfesystem zur Verfügung gestellt wird. An dieser Stelle kann argumentiert werden, dass Anwender ohnehin keine Handbücher oder Dokumentationen lesen. Folgt man den Worten von Joel Spolsky wird diese Behauptung bestätigt [20, Seite 61]: 1. Users don t have the manual, and if they did, they wouldn t read it. 2. In fact, users can t read anything, and if they could, they wouldn t want to.

66 12. Benutzerfreundlichkeit 56 Tatsächlich ist es so, dass Anwender Hilfesysteme oder Handbücher in der Regel erst in Erwägung ziehen, wenn sie das Problem durch Probieren nicht lösen können. Dann ist es wichtig, dass bei der Gestaltung von Hilfesystemen oder Handbüchern die folgenden Gestaltungsregeln beachtet wurden: Entsprechende Hilfesysteme oder Dokumente sollten über geeignete Suchfunktionen verfügen. Die Hilfe sollte sich an den Aufgaben des Anwenders orientieren. Hilfetexte sollten auf keinen Fall zu umfangreich sein, da der Anwender meist eine schnelle Antwort auf sein Problem wünscht.

67 Kapitel 13 Benutzer Dieses Kapitel widmet sich den vielseitigen Aspekten des Benutzers. Zunächst wird die zentrale Rolle des Benutzers in der Programmentwicklung erläutert. In weiterer Folge werden die drei wesentlichen Benutzergruppen unterschieden. In den spezifischeren Unterkapiteln Personas und Szenarien werden die Zielgruppe für TEAPOT sowie deren Bedürfnisse hinsichtlich des Programms definiert. Zuletzt werden in diesem Kapitel noch einmal die gesamten Anforderungen der Benutzerseite zusammengefasst Kennen des Benutzers Für die benutzerfreundliche Gestaltung eines Programms und der zugehörigen grafischen Oberfläche ist es notwendig den späteren Endbenutzer zu kennen. Durch den Kontakt mit dem Endbenutzer kann herausgefunden werden, was seine tatsächlichen Bedürfnisse hinsichtlich des Programms sind. Eine Möglichkeit für den Kontakt mit dem Endbenutzer stellt das persönliche Gespräch dar. Wenngleich ein Gespräch aufschlussreich sein kann, muss beachtet werden, dass die befragte Person möglicherweise fürchtet, falsche Angaben zu machen. Dies führt zu einem verfälschten Bild der Bedürfnisse des Endbenutzers. Das Gleiche gilt, wenn das Gespräch nicht mit dem tatsächlichen Endbenutzer, sondern beispielsweise mit dessen Vorgesetzten geführt wird. Eine weitere Kontaktmöglichkeit ist der Besuch bei den späteren Endbenutzern. Auf diese Weise können die Endbenutzer bei der Erledigung ihrer Arbeit in ihrem gewohnten Umfeld beobachtet werden. Dies gibt Aufschluss darüber, wie die Arbeitsaufgaben im Moment bewältigt werden. Wird bereits ein Programm für die Erledigung der Arbeit eingesetzt, können wichtige Erkenntnisse für den Entwicklungsprozess gewonnen werden. Von dem bestehenden Programm kann unter anderem gelernt werden, mit welchen Oberflächenkonzepten die Benutzer vertraut sind oder welche Programmbefehle für die Aufgabenbewältigung wesentlich sind. Wie bisher deutlich wird, spielt der Endbenutzer eine zentrale Rolle in der Programmentwicklung. Neben dem Endbenutzer gibt es jedoch noch weitere Benutzer, wie zum Beispiel den Systemadministrator. Sie sollten im Entwicklungsprozess ebenso wenig außer Acht gelassen werden, da sie auch mit dem Programm arbeiten werden. In der Theorie erscheint die Kontaktaufnahme mit dem Endbenutzer als ein einfacher Schritt, der notwendig ist, um ein benutzerfreundliches Produkt zu erstellen. In der Realität 57

68 13. Benutzer 58 erschweren jedoch die folgenden Gründe den Kontakt mit dem Endbenutzer [15, Seite 73f]: Die Entwicklungsfirma unterbindet den Kontakt zwischen den Programmentwicklern und den Endbenutzern, weil sie ihre Angestellten schützen möchte. Kennt der Endbenutzer den Programmentwickler, bittet er bei Problemen eher diesen als den eigens eingerichteten Kundendienst um Hilfe. Dies möchte die Entwicklungsfirma verhindern, da der Programmentwickler dadurch von seiner eigentlichen Arbeit abgehalten wird. Die Verkaufsvertreter der Entwicklungsfirma möchten als Einzige mit den Endbenutzern in Kontakt stehen. Sie fürchten, dass Gespräche mit anderen Personen zu Problemen führen. So könnten beispielsweise Gespräche mit den Programmentwicklern bei den Endbenutzern zu Unzufriedenheit mit dem eingesetzten Programm führen. Der Kunde der Entwicklungsfirma stellt die späteren Endbenutzer nur kurze Zeit für Befragungen oder Beobachtungen zur Verfügung. Die späteren Endbenutzer sind nicht länger verfügbar, da es sich entweder um Führungskräfte oder um Gewerkschaftsmitglieder handelt. Während die Führungskräfte hoch bezahlt und kaum entbehrlich sind, lehnen Gewerkschaftsmitglieder Befragungen und Beobachtungen ab. Trotz der hier angeführten Erschwernisse lohnen sich Bemühungen um den Kontakt mit dem späteren Endbenutzer. Theoretische Diskussionen über die Bedürfnisse der Endbenutzer sind zeitintensiv und führen oft zu keinen brauchbaren Ergebnissen. Die Zeit kann für die gegebenenfalls mühselige Kontaktaufnahme mit dem Endbenutzer besser genutzt werden. Nach der Herstellung des Kontakts können von den Endbenutzern Fakten über ihre Bedürfnisse bezogen werden, wodurch eine Zeitverschwendung durch Spekulationen vermieden wird. Bei lang dauernden Entwicklungsprozessen ist zu beachten, dass der einmalige Kontakt zu dem späteren Endbenutzer nicht ausreichen wird. Unter anderem muss die Veränderung der Endanwender über die Zeit des Entwicklungsprozesses berücksichtigt werden. Abschließend macht das nachfolgende Zitat darauf aufmerksam, dass neben dem Kennenlernen des Benutzers auch die Erkenntnis über unterschiedliche Betrachtungsweisen von Endanwendern und Experten ein Schritt in Richtung erfolgreiches Design ist [19, Seite 92]: Der Prozess des Kennenlernens der Anwender hört niemals auf, weil es so viel zu erfahren gibt und weil die Anwender sich dauernd ändern. Jeder Schritt zu einem besseren Verständnis der Anwender und zu der Erkenntnis, dass es Individuen sind, deren Betrachtungsweise sich von der des Designers unterscheidet, ist wahrscheinlich ein Schritt näher zu einem erfolgreichen Design Benutzerwissen und Benutzergruppen Dieser Abschnitt erläutert die drei wesentlichen Faktoren, durch welche sich Benutzerwissen am deutlichsten unterscheiden. Basierend darauf werden die drei großen Benutzergruppen beschrieben Benutzerwissen Drei wichtige Faktoren, durch welche sich Benutzerwissen erheblich unterscheiden kann, sind die Kenntnisse über den Computer im Allgemeinen, über die Schnittstelle und über die Aufgabendomäne.

69 13. Benutzer 59 Abbildung 13.1: Drei Faktoren, wodurch sich Benutzerkenntnisse unterscheiden: Allgemeine Kenntnisse über den Computer, Kenntnisse über die Benutzung einer bestimmten Schnittstelle und Verständnis der Aufgabenstellung (aus [15, Seite 44]). Für den nachfolgenden Abschnitt Benutzergruppen sind vor allem die Kenntnisse über das Schnittstellenkonzept sowie über das Aufgabenkonzept relevant. Dem Wissen über den Computer im Allgemeinen wird bei der Beschreibung der Benutzergruppen keine Aufmerksamkeit geschenkt. Der Begriff Aufgabenkonzept umschreibt, welche Aufgaben mit einem Programm bearbeitet werden können. Mögliche Aufgabengebiete sind Buchhaltung, Textverarbeitung oder Bildarchivierung. Ferner definiert das Aufgabenkonzept den Umfang innerhalb eines konkreten Bereichs. Anhand des Beispiels der Bildarchivierung bedeutet dies, dass möglicherweise nur bestimmte Bildformate in dem System verwaltet werden können. Im Gegensatz dazu beschäftigt sich das Schnittstellenkonzept damit, wie die Benutzeroberfläche aussieht und wie diese zu bedienen ist. Die zentrale Frage ist, ob sich der Benutzer die Funktionalitäten der Schnittschnelle beziehungsweise der Benutzeroberfläche versteht und verwenden kann. Die folgende Abbildung (Abbildung 13.1) zeigt zusammenfassend noch einmal das Zusammenspiel der drei wesentlichen Faktoren des Benutzerwissens. Diese Skizze ist als Würfel mit Mittelpunkt in den sich kreuzenden Achsen zu betrachten und zeigt, dass es viele verschiedene Kombinationen von Vorwissen bei Benutzern geben kann. So kann ein Benutzer zum Beispiel wenig über den Computer und die Schnittstelle wissen, kann aber dennoch ein hohes Wissen über das Aufgabenkonzept vorweisen.

70 13. Benutzer Benutzergruppen Wie bereits durch die unzähligen möglichen Kombinationen an Benutzerwissen deutlich wird, sind Anwender eine inhomogene Menge. Sie unterscheiden sich nicht nur in ihrem Wissen, sondern auch ihren Nutzungsmustern, ihren Präferenzen und hinsichtlich der menschlichen Aspekte (Kultur, Sprache, Alter). Um diese Vielfalt dennoch zu strukturieren, können im Wesentlichen die folgenden drei großen Gruppen unterschieden werden [19, Seite 93]: Anfänger oder erstmalige Anwender Das Aufgaben- und Schnittstellenkonzept eines Programms ist für Anfänger meistens vollkommen unbekannt. Erstanwender sind mit dem Aufgabenkonzept vertraut, haben aber, wie Anfänger, keine Kenntnisse über die Schnittstelle des Programms. Um die Eingewöhnung und die Benutzung des Programms zu erleichtern, ist es vorteilhaft, wenn in dem Programm bekannte Termini verwendet werden. Ferner ist eine eingeschränkte Auswahl an Aktionen dienlich, da sie den Anwender nicht überfordert. Rückmeldungen über erfolgreich abgeschlossene Arbeitsschritte verhelfen dem Benutzer zu einem Erfolgserlebnis und ermutigen ihn zu der weiteren Verwendung des Programms. Erfahrene periodische Anwender Diese Anwendergruppe ist mit dem Aufgabenkonzept vertraut. Für die Erledigung der Standardaufgaben werden mehrere unterschiedliche Programme eingesetzt, wodurch erfahrene periodische Anwender nur oberflächliche Kenntnisse über die Schnittstellenkonzepte dieser Programme haben. Bei dem Lösen von seltenen Aufgaben kommt es für diese Anwendergruppe zu Schwierigkeiten mit dem Schnittstellenkonzept. Für erfahrene periodische Anwender ist ein hoher Wiedererkennungswert der verschiednen eingesetzten Programme wichtig. Dadurch wird es diesen Anwendern erleichtert, sich auch nach einer längeren Benutzungspause wieder in einem Programm zurechtzufinden. Vor dem Ausführen endgültiger Aktionen, wie zum Beispiel dem unwiderruflichen Löschen einer Datei, sollte der Anwender über die Konsequenzen informiert werden. Durch längere Benutzungspausen können Erinnerungslücken entstehen, wodurch der Anwender nicht über die Folgen jeder Aktion in einem Programm bescheid weiß. Ein weiterer wichtiger Punkt zur Unterstützung dieser Anwendergruppe sind gut organisierte Onlinehilfesysteme und Referenzhandbücher. Experten durch regelmäßige Anwendung Eine weitere Bezeichnung für diese Anwendergruppe ist Power User. Sie kennt sich zur Gänze mit dem Aufgaben- und Schnittstellenkonzept eines Programms aus. Die schnelle und störungsfreie Erledigung der Aufgaben hat eine hohe Priorität. Zur Unterstützung dieser Anwender sind Möglichkeiten zur Verkürzung einer Befehlabfolge, wie zum Beispiel Tastaturkürzel oder Makros, unerlässlich. Störungen im Arbeitsfluss, wie automatisch erscheinende Dialogboxen, sind bei dieser Anwendergruppe zu vermeiden Personas In diesem Abschnitt wird zunächst die Bedeutung von Personas im Entwicklungsprozess erläutert. Danach wird auf die Verwendung von Personas für TEAPOT eingegangen.

71 13. Benutzer Allgemeines Im Zentrum der Benutzeroberflächengestaltung steht der Benutzer. Bevor mit der Gestaltung der Benutzeroberfläche begonnen wird, werden in der Regel Recherchen über den Benutzer durchgeführt. Mit Hilfe der Rechercheergebnisse werden einige fiktive Benutzer erstellt. Diese Vorgehensweise wird mehrfach in der Literatur beschrieben. Unter anderem erwähnt der Autor Joel Spolsky, dass sich sonst konkurrierende Benutzeroberflächengestalter darüber einig sind, dass fiktive Benutzer erfunden und beschrieben werden müssen, um eine Benutzeroberfläche gestalten zu können [20, Seite 85]: The best UI designers in the industry may bicker among themselves, but they all agree on one thing: you have to invent and describe some imaginary users before you can design your UI. Fiktiv erfundene Benutzer werden auch als Personas bezeichnet. Jenifer Tidwell beschreibt eine Persona als Repräsentant einer potentiellen Zielgruppe der Mensch-Computer-Schnittstelle [24, Seite 7]: This is a design technique that models the target audiences. For each major user group, you create a fictional person that captures the most important aspects of the users in that group: what tasks they re trying to accomplish, their ultimate goals, and their experience levels in the subject domain and with computers in general. Für jede große Benutzergruppe wird eine Persona entwickelt. Die Beschreibung der Persona fasst die wichtigsten Informationen über eine Benutzergruppe zusammen. Zu diesen Informationen zählen die folgenden Punkte (Vergleich Abbildung 13.2 auf Seite 63): Name, Alter und Beruf Einstufung der Computerkenntnisse sowie des technischen Verständnisses Beschreibung des Arbeitsumfelds und relevanter Hintergrundinformationen Motive und Ziele Aufgaben Besondere Anforderungen Zusätzlich zu den oben angeführten Angaben wird die Persona mit einem Foto versehen. Durch ein Foto gewinnt die Benutzerbeschreibung an Lebendigkeit. Des Weiteren ist es hilfreich um sich mit dem fiktiven Benutzer zu identifizieren. Es wird leichter sich die Person mit ihren Bedürfnissen vorzustellen und sie in Diskussionen mit anderen Teammitgliedern über die Benutzeroberfläche einfließen zu lassen. Benutzerbeschreibungen in Form von Personas fassen die durch Recherchen erhobenen Daten zusammen und hauchen ihnen Leben ein. Durch Personas erhalten die gewonnen Erkenntnisse einen Namen und ein Gesicht [5, Seite 54]:

72 13. Benutzer 62 You can make your users more real by turning them into personas (sometimes called user models or user profiles). A persona is a fictional character constructed to represent the needs of a whole range of real users. By putting a face and a name on the disconnected bits of data from your user research and segmentation work, personas can help ensure that you keep the users in mind during the design process. In dem Entwicklungsprozess garantieren Personas, dass der spätere Endbenutzer stets im Hinterkopf behalten wird. Dadurch werden die Bedürfnisse der späteren Endbenutzer im Entwicklungsprozess besser berücksichtigt. Da Personas im Laufe der Entwicklung fast wie kleine Freunde werden, sind sie treue Begleiter, die auch stets daran erinnern, den momentanen Stand der Entwicklung zu hinterfragen. An Personen zu denken, die tatsächlich existieren könnten, verleiht Gestaltern und Programmierern das nötige Einfühlungsvermögen um während des Entwicklungsprozesses die Bedürfnisse der späteren Endbenutzer zu berücksichtigen [20, Seite 86]: Thinking about a real person gives you the empathy you need to make a feature that serves that person s need Personas für TEAPOT Der vorangehende Abschnitt hat den hohen Stellenwert der Personas hinsichtlich Benutzerfreundlichkeit in dem Entwicklungsprozess eines Produkts deutlich gemacht. Aufgrund der hohen Relevanz wurden für das Projekt TEAPOT fünf verschiedene Personas entwickelt. In der Abbildung 13.2 auf der nächsten Seite wird Matthias Mittermayr, einer der fiktiv erfundenen Benutzer, vorgestellt. Bei ihm handelt es sich um einen zweiundzwanzigjährigen Studenten der FH Hagenberg. Bedingt durch sein Studium verfügt Matthias Mittermayr über hohe Computerkenntnisse sowie über ein hohes technisches Verständnis. Für die Durchführung seiner Semesterprojekte möchte er die benötigten Dateien zeit- und ortunabhängig verwalten. Ein weitere Anforderung von Matthias Mittermayr ist eine betriebssystemunabhängige Verwaltung der Projektressourcen. Für Gruppenprojekte möchte er auch Studienkollegen Texte, Grafiken oder andere Dateien zur Verfügung stellen. Ähnlich der hier vorgestellten Persona Matthias Mittermayr geben die vier weiteren Personas Einblick in deren Wissensstand, deren Aufgabengebiete und deren Anforderungen. Die detaillierten Beschreibungen der weiteren Personas sind auf der beigelegten DVD zu finden. Folglich sind Personas eine Unterstützung bei der Definition der Anforderungen an ein Produkt, wie es eine Benutzeroberfläche oder ein Programm ist. Außerdem sind sie bei der Zielgruppendefinition dienlich. Für TEAPOT lassen sich basierend auf den entwickelten Personas und unter Berücksichtigung der Produktbeschreibung (siehe Abschnitt 3.2) zwei unterschiedliche Zielgruppen zusammenfassen: Benutzer der quelloffenen Version Das Alter dieser Zielgruppe reicht von fünfzehn bis etwa vierzig Jahren. Die Zielgruppe setzt TEAPOT entweder im privaten oder im geschäftlichen Rahmen ein. Bei der geschäftlichen Nutzung sind die Benutzer jedoch nicht auf die Unterstützung durch die Entwicklungsfirma angewiesen. Dieser Fall tritt beispielsweise ein, wenn in einer kleinen Firma ein Server vorhanden ist, auf dem das System installiert werden kann.

73 13. Benutzer 63 Abbildung 13.2: Beispiel einer Persona. Durch hohe Computerkenntnisse und ein hohes technisches Verständnis traut sich die Zielgruppe zu, TEAPOT zu installieren und auszuprobieren. Die Benutzer wissen aus Erfahrung, dass sie das System nicht beschädigen können. Bei etwaigen Problemen weiß sich die Zielgruppe durch das Nachlesen in der Dokumentation oder durch das Aufsuchen von Foren zu helfen. Unter Umständen nimmt die Zielgruppe eine vorhandene Programmierschnittstelle (API1 ) 1 Application Programming Interface

74 13. Benutzer 64 zur Hand und entwickelt eigene Module für das System. Ein Modul kann das System um neue Funktionalitäten erweitern und anderen Benutzern des Systems zur Verfügung gestellt werden. Zumeist sind die Benutzer dieser Zielgruppe Mitglieder in der zu dem System zugehörigen virtuellen Gemeinschaft. Benutzer der kostenpflichtigen Version Personen, die dieser Zielgruppe angehören, sind zumeist Angestellte einer Firma und dadurch reine Anwender. Die Firma hat sich entschieden TEAPOT zur zeit- und ortunabhängigen Verwaltung der vorhandenen Ressourcen zu installieren. Die Domänenbereitstellung und die Betreuung durch die Entwicklerfirma werden gegen Gebühren von der Firma in Anspruch genommen. Das Alter dieser Zielgruppe reicht in etwa von zwanzig Jahren bis zur Pensionierung. Die Zielgruppe verwendet TEAPOT nicht aus eigener Motivation. Die Verwendung des Systems ist durch den Arbeitgeber vorgegeben. Für die Zielgruppe kommt es nicht in Frage, TEA- POT im privaten Rahmen zu nutzen und sich auf diesem Weg mehr Wissen über das System anzueignen. Die Aufgaben dieser Zielgruppe beschränken sich auf das Verwalten der vorhandenen Ressourcen. In manchen Fällen möchte die Zielgruppe Zugriff auf die Benutzerverwaltung haben. Selten gibt es Benutzer, die lediglich für sie bereitgestellte Ressourcen herunterladen möchten. Die Zielgruppe wird nie mit der Verwaltung von Domänen oder mit der Installation von TEAPOT in Berührung kommen Szenarien Dieser Abschnitt widmet sich dem Einsatz von Szenarien im Entwicklungsprozess. Nachfolgend wird die Verwendung von Szenarien für TEAPOT diskutiert Allgemeines Im Gegensatz zu den in Kapitel 7 vorgestellten Anwendungsfällen sind Szenarien eine Methode zur Handlungs-, Kontext- und Aufgabenmodellierung. Durch Szenarien werden die Handlungen des Benutzers in seiner gewohnten Umgebung zur Erledigung seiner Aufgaben beschrieben. Dadurch können typische Aufgaben und Tätigkeiten des Benutzers eruiert werden. Des Weiteren können auf diese Weise die beschriebenen Aufgaben nach ihrer Häufigkeit und Wichtigkeit bewertet werden. Vereinfacht dargestellt sind Szenarien jedoch nichts anderes als Geschichten über den Benutzer und seine Handlungsschritte [2, Seite 46]: Scenarios are stories stories about people and their activities. Für Szenarien ist es charakteristisch, dass sie als Prosatexte verfasst werden. Des Weiteren berücksichtigen sie neben kontextbezogenen Beschreibungen auch personenspezifische Merkmale. Zu diesen Merkmalen zählen unter anderem das Alter, die Herkunft oder das Benutzerwissen einer Person. Ferner zeichnet Szenarien aus, dass sie konkret und flexibel zugleich sind. Konkret sind Szenarien dahingehend, dass sie Lösungsvorschläge anbieten und bestimmten Situationen interpretieren. Die Flexibilität begründet sich in der einfachen und intuitiven Erstellung der Szenarien. Zusätzlich sind die Texte leicht zu erweitern oder zu überarbeiten [2, Seite 54]:

75 13. Benutzer 65 Scenarios of use reconcile concreteness and flexibility. They are concrete in the sense that they simultaneously fix an interpretation of the design situation and offer a specific solution. [... ] At the same time, scenarios are flexible in the sense that they are deliberately incomplete and easily revised or elaborated. Ein Nachteil von Szenarien ist die schwach strukturierte Form. Besonders bei umfangreichen Projekten kann der Einsatz von Szenarien einen erhöhten Verwaltungsaufwand bedeuten. Die Aktualisierung der Szenarien kann sich je nach Projektgröße als aufwendig erweisen. Dennoch überwiegen die Vorteile bei dem Einsatz von Szenarien. Ein wesentlicher Vorteil ist die Sprache, in der Szenarien verfasst werden. Es handelt sich dabei um eine Sprache, die nicht auf die Verwendung von Fachausdrücken reduziert ist. Die allgemein gehaltene Sprache, in der Szenarien verfasst sind, wird von allen beteiligten Projektmitgliedern verstanden. Dies ermöglicht, dass unterschiedlichste Experten miteinander über ein Projekt kommunizieren können. Auf diese Weise wird niemand von dem Entwicklungsprozess des Projekts ausgeschlossen [17, Seite 23]: All project members can speak the language of scenarios. [...] Scenarios help to integrate many different kinds of knowledge and experience by simplifying communication among different kinds of experts. Die Abbildung 13.3 auf der nächsten Seite zeigt zu den bereits erwähnten Punkten noch weitere Vorteile und Charakteristika von Szenarien auf. Dazu zählt unter anderem, dass Szenarien den momentanen Stand der Entwicklung dokumentieren. Dennoch treiben sie zugleich den Entwicklungsprozess voran, da durch die Analyse des aktuellen Projektstandes neue Ideen entstehen und leicht in die Szenarien integriert werden können. Des Weiteren unterstützen Szenarien die Entwicklung neuer Funktionalitäten in einem Projekt. Mit Hilfe der Szenarien wird die Diskussion über mögliche Konsequenzen der neuen Funktionalitäten für die Benutzerfreundlichkeit erleichtert. Ferner wird die Diskussion über das Projekt im Team durch die lebendige Beschreibung von Szenarien angeregt. Die Projektmitglieder können sich ein Bild von den späteren Einsatzbedingungen des Programms machen und dadurch, wie auch bei den Personas, die Bedürfnisse der späteren Endbenutzer besser berücksichtigen. Daraus resultiert, dass Szenarien eine wesentliche Grundlage für die Kommunikation im Projektteam bilden und eine Basis für Diskussionen über das Projekt und dessen Entwicklungsstand schaffen Szenarien für TEAPOT Wie der vorangehenden Abschnitt erläutert, haben Szenarien einen positiven Einfluss auf den Entwicklungsprozess eines Produktes. Aus diesem Grund wurden für TEAPOT fünf verschieden Szenarien entwickelt. Jedes der Szenarien korrespondiert jeweils mit einer der fünf entwickelten Personas. In Abbildung 13.4 auf Seite 67 wird das Szenario zu der Persona Michaela Ausec vorgestellt. Bei Michaela Ausec handelt es sich um die Chefredakteurin eines monatlich erscheinenden Frauenmagazins. Für den Sommer hat die Redaktion einen Praktikanten eingestellt, der beim Einpflegen der vorhanden Dateien in das erst kürzlich installierte Media Asset Management System behilflich sein soll. Damit der Praktikant Zugriff auf das System hat, muss Michaela Ausec einen neuen Benutzer mit eingeschränkten Rechten anlegen.

76 13. Benutzer 66 Abbildung 13.3: Verwendung von Szenarien in der Softwareergonomie (aus [17, Seite 21]). Ähnlich dem hier vorgestellten Szenario beschreiben die vier weiteren Szenarios (siehe DVD) Aufgaben und Handlungsabläufe, die typisch für die korrespondierende Persona sind. Dabei nehmen die Szenarien Rücksicht auf die personenspezifischen Merkmale und das Umfeld der Persona. Die Szenarien dienen der Aufgabenanalyse hinsichtlich des Aufgabenkonzepts von TEA- POT. Des Weiteren können mit Hilfe der Szenarien Rückschlüsse gezogen werden, welche der Aufgaben für den späteren Endbenutzer von hoher Relevanz sind. Die folgende Abbildung 13.5 auf der nächsten Seite schlüsselt die Aufgaben auf, die in den entwickelten Szenarien beschrieben werden. Die Aufgaben werden für jede Persona nach Relevanz und Einsatzhäufigkeit gewichtet. Eine Aufzählung der Aufgaben sowie deren Gewichtung verschaffen während des Entwicklungsprozesses einen Überblick. Silvester Körnig repräsentiert einen Systemadministrator. Der Tabelle kann entnommen werden, dass das Anlegen von Domänen, Benutzern und Gruppen für ihn von hoher Relevanz ist. Als Systemadministrator muss er am häufigsten administrative Aufgaben bewältigen. Aus diesem Grund hat er wenig Interesse an den Hauptfunktionalitäten des Media Asset Management Systems. Im Gegensatz dazu sind für Anwender, wie Claudia Staringer oder Michaela Ausec, die Hauptfunktionalitäten des Media Asset Management Systems vordergründig. Die Tabelle zeigt, dass das Hoch- oder Herunterladen von Assets den Büroalltag der beiden Frauen prägt.

77 13. Benutzer 67 Anlegen eines neuen Benutzers (Michaela Ausec) Da die Redaktion erst seit Kurzem über ein Media Asset Management System verfügt, gibt es noch viele Materialien (Bilder, Texte), die in das System eingepflegt werden müssen. Zur Unterstützung bei dieser Tätigkeit hat die Redaktion für diesen Sommer einen Praktikanten eingestellt. Michaela Ausec meldet sich in dem Media Asset Management System als Chefredakteurin an. Sie möchte für den Praktikanten einen neuen Benutzer anlegen, der das Recht hat Assets in das System aufzuladen und zu bearbeiten. Bevor sie mit ihrer geplanten Tätigkeit beginnt, überprüft sie ihre persönliche Startseite auf Neuigkeiten. Es wurde für sie eine Zusammenstellung von einem Kollegen hinterlegt. Das interessiert Michaela Ausec im Moment allerdings nicht. Sie klickt in dem Menü auf den Karteireiter mit dem Titel Administration. Das Menü verändert sein Erscheinungsbild. Der ausgewählte Karteireiter wird als aktiv gekennzeichnet und es wird ein anderes Untermenü eingeblendet. Im Untermenü klickt Michaela Ausec auf den Menüpunkt mit dem Titel Benutzer. Es wird ihr eine Seite angezeigt, auf der sie den neuen Benutzer anlegen kann. Sie macht alle notwendigen Angaben über den neuen Benutzer und wählt eine Benutzergruppe aus, die über die passenden Rechte verfügt. Abschließend speichert Michaela Ausec den Benutzer und notiert die Zugangsdaten für den Praktikanten. Abbildung 13.4: Beispiel für ein Szeanrio. Abbildung 13.5: Auflistung und Gewichtung der Aufgaben.

78 13. Benutzer 68 Für Michaela Ausec ist zudem die Benutzerverwaltung wichtig, da sie in dem System über die Rechte der Chefredakteurin (siehe Akteure) verfügt. Genaueres über die Personas und ihre Aufgaben ist auf der beigelegten DVD zu finden. Dort sind alle Personas und Szenarien in kompletter Ausführung vollständig beschrieben Anforderungen an TEAPOT aus Anwendersicht Resultierend aus den entwickelten Personas und den Szenarien fasst die nachstehende Liste die Anforderungen aus Anwendersicht zusammen. Diese Liste ist als Ergänzung zu den Anwendungsfällen (siehe Anwendungsfälle) zu betrachten. Das Programm soll einfach in der Bedienung sein. Das heißt, dass die Bedienung des Programms ohne das vorangehende Lesen eines Handbuchs bzw. eine Dokumentation möglich sein soll. Dennoch soll ein gut organisiertes Handbuch bzw. eine gut organisierte Dokumentation vorhanden sein. Das Programm soll mit unterschiedlichen Betriebssystemen verwendet werden können. Mit dem Programm soll die zentrale Verwaltung von Materialien ermöglicht werden. Das schließt den zeit- und ortunabhängigen Zugriff auf vorhandene Materialien mit ein. Durch das Programm sollen Materialien unterschiedlicher Datentypen verwaltet werden können. Zu diesen Datentypen zählen Audiodateien, Textdokumente, Bilder, 3D-Modelle und Videodateien. Materialien sollen in das Programm eingespielt und ausgelesen werden können. Dies soll jeweils für einzelne und mehrere Dateien auf einmal möglich sein. Das Programm soll die Möglichkeit bieten, die vorhanden Materialien zu strukturieren. Es soll eine Sortierung nach Projekten, Kategorien und Datentypen möglich sein. Die vorhandenen Materialien sollen mit beliebig vielen Schlagworten versehen werden können. Das Durchsuchen der Materialien sowie die gezielte Suche nach Materialien soll möglich sein. Die gezielte Suche nach Materialien soll möglichst schnell Suchergebnisse zurückliefern. Es soll möglich sein, relevante Materialien zusammenzustellen. Solch eine Zusammenstellung von Materialien soll gespeichert und weitergegeben werden können. Des Weiteren soll solch eine Zusammenstellung herunter geladen werden können. Wenn ein Benutzer über die benötigte Berechtigung verfügt, soll er Benutzer, Gruppen und Domänen verwalten können. Das Verwalten einer Domäne erfordert Administratorrechte und beinhaltet die Benutzerverwaltung. Die Benutzerverwaltung ist auch unabhängig von der Domänenverwaltung mit einer eingeschränkten Berechtigung möglich.

79 Kapitel 14 Überlegungen zur Benutzeroberfläche In diesem Abschnitt werden zunächst Unterschiede zwischen Web- und Desktopapplikation vorgestellt. Des Weiteren wird die Entscheidung für eine Webapplikation begründet. Abschließend wird die Vorgehensweise zur Entwicklung der Benutzeroberfläche erläutert Vergleich zwischen Web- und Desktopapplikation Zu Beginn der Entwicklung der Benutzeroberfläche muss die Entscheidung getroffen werden, ob später eine Web- oder eine Desktopapplikation zum Einsatz kommen soll. Dazu werden die Unterschiede beziehungsweise die besonderen Merkmale von Internet und Desktop betrachtet. Ein Unterschied liegt in dem Such- sowie in dem Durchsuchverhalten. In der Abbildung 14.1 auf der nächsten Seite wird das typische Verhalten eines Internetbenutzers dargestellt, wenn er auf der Suche nach einer bestimmten Information ist. Nach dem Aufruf der Webseite entscheidet sich der Benutzer, ob er Lust zum Durchsuchen der Seite hat oder ob er gezielt mittels des Suchfelds nach der Information sucht. Entscheidet sich der Benutzer für das Durchsuchen der Webseite, erfolgt ein Klick auf einen im Menü angebotenen Bereich. Im nächsten Schritt wählt der Benutzer einen der angebotenen Unterbereiche aus und sieht den Inhalt durch. Ist das Ergebnis einer dieser Schritte für den Benutzer erfolglos, kehrt er zu dem vorhergehenden Schritt oder an den Anfang des Prozesses zurück. Kann der Benutzer schließlich die gewünschte Information finden, verlässt er zufrieden die Webseite. Ist es dem Benutzer nicht möglich die gewünschte Information zu finden, verlässt er frustriert die Webseite. Kann der Benutzer eine Information ähnlich der gewünschten Information finden, ist es wahrscheinlich, dass er die gezielte Suche mittels des Suchfelds einsetzt. Für die gezielte Suche gibt der Benutzer eine Abfrage in das Suchfeld ein. Nach Absetzen der Suche prüft der Benutzer das Ergebnis. Erscheint ihm das Ergebnis als brauchbar, wird das Ergebnis nach passenden Treffern durchsucht. Ist einer dieser Schritte erfolglos, kehrt der Benutzer zu einem vorhergehenden Schritt oder an den Anfang des Prozesses zurück. Findet der Benutzer unter den Treffern die gewünschte Information, verlässt er zufrieden die Webseite. Kann der Benutzer die gewünschte Information auf der Webseite nicht finden, verlässt der Benutzer frustriert die Webseite. Im Gegensatz dazu steht das Such- und Durchsuchverhalten eines Benutzers auf seinem eigenen Computer. Der Benutzer sucht nach einer Information oder einer Datei in einer bestimmten Suchmenge. Die Dateien auf dem eigenen Computer werden durch den Benutzer in einem selbst bestimmten System abgelegt, wodurch er ohne Hilfe eines Suchfeldes gezielt 69

80 14. Überlegungen zur Benutzeroberfläche 70 Abbildung 14.1: Such- und Durchsuchverhalten im Internet (aus [9, Seite 56]). zu der gewünschten Information oder Datei navigieren kann. Die Suche nach einer Information oder einer Datei mittels eines Suchfelds wird auf dem Desktop nur selten in Anspruch genommen. Der Unterschied zwischen dem Durchsuch- und Suchverhalten im Internet und auf dem Desktop ist folglich durch die zu durchsuchenden Mengen bestimmt. Im Internet möchte der Benutzer eine ihm unbekannte und unbestimmte Menge durchsuchen. Auf dem Desktop hingegen ist dem Benutzer die zu durchsuchende Menge bekannt und endlich. Die Abbildungen 14.2 auf der nächsten Seite und 14.3 auf Seite 72 gehen nochmals konkret auf den Unterschied zwischen dem Durchsuchverhalten auf dem Desktop und im Internet ein.

81 14. Überlegungen zur Benutzeroberfläche 71 Abbildung 14.2: Durchsuchen des Desktop unter Mac OS X. Im Internet treten Ladezeiten unbestimmter Länge auf. Das Durchsuchen auf dem Desktop ist unabhängig von diesen Ladezeiten. Die Interaktion mit dem lokalen System beziehungsweise mit dem systemeigenen Finder ist daher unmittelbar. Der Benutzer erhält von dem System eine sofortige Reaktion. Des Weiteren kann im Finder auf dem Desktop die Ansicht geändert werden. Der Benutzer kann entscheiden, ob ihm ausschließlich der Inhalt des aktuell geöffneten Ordners angezeigt oder zusätzlich dazu auch das hierarchische Ordnersystem (siehe Abbildung 14.2) präsentiert werden soll. Abbildung 14.3 auf der nächsten Seite zeigt eine Lösung zum Durchsuchen vom Dateien im Internet. Bei diesem Beispiel ist es dem Benutzer nicht möglich die Ansicht zu ändern. Er kann zu einem Zeitpunkt nur den Inhalt der aktuell ausgewählten Kategorie sehen. Des Weiteren weiß der Benutzer bei diesem Beispiel lediglich, welche Kategorie über der aktuell ausgewählten Kategorie liegt. Er erhält keine Information darüber, welche Kategorien parallel zu der ausgewählten Kategorie zur Verfügung stehen. Die Präsentation der Kategoriehierarchie muss jedoch nicht auf die in Abbildung 14.3 auf der nächsten Seite dargestellte Weise gelöst werden. Das Aussehen und die Funktionalität können dem Finder auf dem Desktop nachempfunden werden, wodurch dem Benutzer beim Durchsuchen der Dateien mehr Möglichkeiten geboten werden können. Dennoch bleibt das große Hindernis der unvorhersehbaren Ladezeiten beim Durchsuchen im Internet bestehen. Ein weiterer Unterschied besteht in der Menüführung. Durch die zahlreichen Möglichkeiten in der Gestaltung von Webseiten trifft man auf viele unterschiedliche Menüführungen. Die folgenden Menüarten werden sowohl einzeln als auch in Kombination miteinander eingesetzt:

82 14. Überlegungen zur Benutzeroberfläche 72 Abbildung 14.3: Durchsuchen der Demonstrationsversion von AssetBank. horizontale Menüs mit Platzierung am oberen oder unteren Seitenrand und vertikale Menüs mit Platzierung am linken oder rechten Seitenrand. Zusätzlich dazu unterscheiden sich die Menüs in ihrer Form und Farbe. Bei Desktopapplikationen ist es hingegen Standard, dass das Applikationsmenü horizontal am oberen Bildschirmrand angeordnet ist. Manche Applikationen bieten zusätzlich zu dem Standardmenü vertikal angeordnete Menüs. Diese werden links oder rechts neben dem Hauptinhalt der Applikation angezeigt. Ein Beispiel hierfür sind die Formatvorlagen in Microsoft Office Word 2003 für Windows. Andere Applikationen bieten zusätzlich zu dem Standardmenü freibewegliche Menüblöcke, die beliebig konfiguriert und auf dem Bildschirm verschoben werden können. Ein Beispiel für diese Variante ist das Programm Adobe Photoshop. Die Anordnung der Menüs kann in diesem Programm auch gespeichert werden, sodass der Benutzer stets an seinen individualisierten Arbeitsplatz zurückkehren kann. Wie bereits im vorangehenden Absatz kurz erwähnt, bietet die Gestaltung von Webseiten unzählige Möglichkeiten. Im Internet gleicht kaum eine Webseite einer anderen. Desktopapplikationen dagegen sind im Aussehen zumeist sehr ähnlich. Dies ist nicht nur durch die standardmäßige Anordnung der Applikationselemente bedingt, sondern auch durch das auf die meisten

83 14. Überlegungen zur Benutzeroberfläche 73 Applikationen angewandte Systemfarbschema beziehungsweise Systemerscheinungsbild. Dabei ist die einheitlich gehaltene Präsentation von Desktopapplikation nicht als Nachteil zu sehen, da auf diese Weise die Heuristik der Konsistenz und Standardkonformität befolgt wird Entscheidung für eine Webapplikation Für das Projekt TEAPOT fiel die Entscheidung unter Berücksichtigung der in dem vorhergehenden Abschnitt 14.1 angeführten Unterschiede auf den Entwurf einer Webapplikation. Diese Entscheidung wird im Folgenden begründet. Heutzutage verwendet ein Benutzer verwendet unterschiedliche Computer an unterschiedlichen Orten. Dadurch ist die Onlinedatenspeicherung für den Benutzer der einfachste Weg persönliche Daten und Präferenzen zeit- und ortunabhängig zu halten [10, Seite 12]: People are using different computers at home, at work, at school, in cafes, and on their phones. Hosting the data online is the most natural way to take their data and preferences with them. Die zentrale Datenspeicherung auf einem Server wäre zugegebenermaßen auch bei der Verwendung einer Desktopapplikation möglich. Jedoch bringt die Webapplikation gegenüber der Desktopapplikation einen wesentlichen Vorteil mit sich: Die Webapplikation muss nicht auf dem Computer installiert werden. Von einer Desktopapplikation muss der Benutzer erst überzeugt sein, damit er diese installiert. An dieser Stelle beißt sich die Katze bereits in den Schweif: Um von der Desktopapplikation überzeugt zu werden, muss der Benutzer sie zumeist installieren. Denn nur durch Ausprobieren kann der Benutzer die Brauchbarkeit des Programms beurteilen [10, Seite 12]: Desktop applications suffer from something of a cath-22 situation: a user needs to be convinced an application is useful enough to bother installing, but she often can t make that call until she s installed it. In contrast, most web applications allow a user to jump in straight away and immediately begin using the application, avoiding an installation process altogether. Im Gegensatz dazu können Webapplikationen ohne Installation benutzt werden. Der Benutzer muss einfach nur damit beginnen die Applikation zu verwenden. Er muss nicht darüber nachdenken, ob die Webapplikation tatsächlich nützlich für ihn ist oder nicht. Die bisherigen Begründungen berücksichtigen die Bedürfnis des Anwenders. Aus Sicht des Entwicklers sind andere Gründe für die getroffene Entscheidung ausschlaggebend. Die Produktivität einer Webapplikation ist oft höher als die der Desktopalternative. Dies trifft vor allem zu, wenn häufig neue Versionen für verschiedene Plattformen veröffentlicht werden. Beim Einsatz einer Webapplikation muss nur ein Produkt bearbeitet werden. Dies ermöglicht zusätzlich eine stufenweise Aufrüstung der Applikation, welche attraktiver ist als das Umstellen auf eine komplett neue Version [10, Seite 12]: For developers, a modern web application is often more productive than a conventional GUI alternative, especially if you want frequent releases on multiple platforms. Developers only have to code a single product for all platforms; they can upgrade the application incrementally rather than in big bang style. And on the server, where most of the logic lives, they can use whatever programming language and libraries they care to work with.

84 14. Überlegungen zur Benutzeroberfläche 74 Aus dem Einsatz einer Webapplikation ergibt sich eine weiterer Vorteil: Auf dem Server, wo der Großteil der Programmlogik liegt, können beliebige Programmiersprachen und Bibliotheken eingesetzt werden. Zusätzlich entsteht ein Vorteil für die Benutzerseite: Die Anforderungen auf der Benutzerseite reduzieren sich auf einen aktuellen Webbrowser. Ferner ist es im Interesse des Entwicklers, dass ein Programm eine möglichst hohe Verbreitung erzielt. Der Einsatz einer Desktopapplikation ist diesem Ziel nicht dienlich, da zumeist nur die Benutzer eines Betriebssystems erreicht werden. Neuere Plattformen, wie zum Beispiel ein Mehrzwecktelefon, werden von Desktopapplikationen ebenso vernachlässigt wie andere Betriebssysteme. Im Gegensatz dazu haben Webapplikationen eine weitaus höhere Reichweite, da sie plattformunabhängig sind [10, Seite 13]: Application developers are usally interesting in supporting as wide a user base as possible. Those who just target MS-Windows will not only miss out on other desktop options like Apple and Linux, but also on less conventional platforms like smartphones, home entertainment systems, and game consoles. A web application is often more flexible way to target this newer platforms Vorgehensweise Obwohl das Projekt TEAPOT an der Fachhochschule Hagenberg bereits existiert, wird TEA- POT in dieser Diplomarbeit als ein neues eigenständiges Projekt betrachtet. Aus diesem Grund wurde im Zuge des Projekts erneut eine Zielgruppendefinition und eine Anforderungsanalyse durchgeführt. Die Definition der Zielgruppe basiert auf fiktiv erfundenen Personas. Die Anforderungen an das Projekt aus Anwendersicht leiten sich zum Teil von den Personas und zum Teil von den Szenarien ab. Die neu erstellte Zielgruppendefinition und Anforderungsanalyse bilden die Grundlage für die Entwicklung einer neuen Benutzeroberfläche für eine Webapplikation (siehe 14.2). Nach dem Entwurf der Benutzeroberfläche unter Berücksichtigung der Anforderungen wurde die Benutzerfreundlichkeit der Benutzeroberfläche mit Hilfe von Interviews überprüft. Außerdem wurde durch die Interviews mit unterschiedlichen Personen das Benutzermodell abgeglichen. Unter dem Benutzermodell versteht man die Erwartungshaltung des Benutzers gegenüber der Benutzeroberfläche. Zusätzlich wurde mit Hilfe der Interviews versucht den späteren Endbenutzer kennen zu lernen. Diese Aufgabe erwies sich als problematisch, da die Kontaktaufnahme mit Personen aus der Medienbranche nicht möglich war. Dennoch deckten die Befragungen von Studenten und Webentwicklern hinsichtlich der Benutzerfreundlichkeit der Benutzeroberflächen einen Teil der definierten Zielgruppe ab. Des Weiteren war das Gespräch mit Privatpersonen und Softwareentwicklern hilfreich bei der Weiterentwicklung der Benutzeroberfläche. Folgt man den Worten von Joel Spolsky, ist es letztlich für den Aspekt der Benutzerfreundlichkeit aber nicht entscheidend, ob tatsächlich die späteren Endbenutzer in dem Interview befragt werden [20, Seite 92]: Do hallway usability tests, also known as fifty-cent usability tests, when you first design a new feature. The basic idea is that you just show a simple drawing or screen shot of your proposed design to a few innocent bystanders [... ], and ask them how they would use it.

85 14. Überlegungen zur Benutzeroberfläche 75 Wichtig ist, dass unterschiedliche Personen zu den Entwürfen von neuen Funktionen oder neuen Benutzeroberflächen befragt werden. Die Erwartungshaltung gegenüber einem Entwurf kann auch durch die Befragung unbeteiligter Personen erfasst werden. Insgesamt wurden fünf Befragungen zu dem Entwurf der Benutzeroberfläche durchgeführt. Die Anzahl der Befragungen begründet sich in den Worten von Joel Spolsky. Um zu erfahren, was die Benutzer von der Benutzeroberfläche denken oder wo etwaige Schwachstellen hinsichtlich der Benutzerfreundlichkeit liegen, genügt es fünf oder sechs Personen zu befragen. Bei der Befragung von mehr als sechs Personen erfährt man zumeist nicht mehr Neues über den vorgelegten Benutzeroberflächenentwurf [20, Seite 10f]: Almost everybody who does usability testing for living agrees that five or six users is all you need. After that, you start seeing the same results again and again, and any additional users are just a waste of time. The reason being that you don t particularly care about the exact numerical statistics of failur. You simply want to discover what most people think. Die Ergebnisse der Befragungen wurden anschließend bei einer Überarbeitung der Benutzeroberfläche berücksichtigt. Dadurch konnte die Qualität der Benutzeroberfläche erheblich gesteigert werden. Wie sich sie die Entwicklung der Benutzeroberfläche im Detail gestaltet hat, ist in dem Abschnitt Entwicklung der Benutzeroberfläche beschrieben. Für das Entwerfen guter Software einschließlich einer gut durchdachten Benutzeroberfläche können die folgenden sechs Schritte nach Joel Spolsky als Leitfaden zur Hand genommen werden [20, Seite 87]: Designing good software takes about six steps: 1. Invent some users. 2. Figure out the important activities. 3. Figure out the user model how the user will expect to accomplish those activities. 4. Sketch out the first draft of the design. 5. Iterate over your design again and again, making it easier and easier until it s well within the capabilities of your imaginary users. 6. Watch real humans trying to use your software. Note the areas where people have trouble, which are probably areas where the program model isn t matching the user model. Diesem Leitfaden wurde auch für den Benutzeroberflächenentwurf von TEAPOT zum größten Teil Folge geleistet. Zunächst wurden einige Benutzer erfunden. Mittels der Szenarien wurden die wichtigsten Aufgaben aufgeschlüsselt und ein Benutzermodell erstellt. Basierend darauf wurde der Entwurf für die Benutzeroberfläche erstellt. Der Entwurf wurde schließlich überarbeitet und an die Fähigkeiten der erfundenen Benutzer angepasst. Lediglich der letzte Schritt konnte für das Projekt TEAPOT nicht umgesetzt werden, da die Benutzeroberfläche im Rahmen einer Studie entworfen wurde. Aus diesem Grund gibt es keine technische Umsetzung der Benutzeroberfläche, die durch Anwender getestet werden könnte.

86 Kapitel 15 Entwicklung der Benutzeroberfläche In diesem Kapitel wird zu Beginn die Befragung vorgestellt, die zur subjektiven Beurteilung des Benutzeroberflächenkonzepts durch den potentiellen Endbenutzer genutzt wurde. Im Anschluss daran beschäftigt sich ein Unterkapitel mit dem allgemeinen Aspekt der Benutzeroberfläche. Danach wird die Benutzeroberfläche Seite für Seite beschrieben und analysiert. In die Analyse fließen die Ergebnisse der Befragung über die Benutzeroberfläche ein. Außerdem wurden diese in der Weiterentwicklung des Benutzeroberflächenkonzepts berücksichtigt Befragung zur Benutzeroberfläche Die Befragung diente der subjektiven Beurteilung der Benutzeroberfläche durch potentielle Endbenutzer. Dies schloss das persönliche Empfinden bezüglich der Übersichtlichkeit der vorgestellten Seitenentwürfe der befragten Personen mit ein. Außerdem beurteilten die befragten Personen die angebotenen Funktionalitäten hinsichtlich der Verständlichkeit. Ein wesentlicher Teil der Befragung war jedoch auch die Überprüfung der Erwartungshaltung des Benutzers. Dabei lautete die zentrale Frage, ob die befragten Personen den Entwurf in jener Weise auffassen, wie es von dem Entwickler des Benutzeroberflächenkonzepts vorgesehen ist. Folgend wird der Fragebogen vorgestellt, auf welchem die durchgeführten Befragungen basieren. In Kapitel 14 wird näher auf die Personenauswahl für die Befragungen eingegangen. Dabei wird die berufliche Herkunft der Personen sowie die Anzahl der Befragungen diskutiert. Zu Beginn der Befragung wurden von dem Gesprächspartner einige persönliche Angaben verlangt: Alter, Beschäftigungsverhältnis, Branche, Selbsteinschätzung der Computerkenntnisse und des technischen Verständnisses. Ferner war anzugeben, wofür der Computer eingesetzt wird und wie viele Stunden pro Woche die Person im Schnitt vor dem Computer verbringt. Diese Fragen dienten dazu ein ungefähres Profil der befragten Personen zu erstellen. In den folgenden Abbildungen (siehe Abbildung 15.1 bis Abbildung 15.4) sind die Angaben der befragten Personen dargestellt. Im Anschluss daran wurden die Vorkenntnisse des Gesprächpartners abgefragt. Dazu wurden allgemeine Fragen zu dem Thema Media Asset Management sowie zu dem Thema Virtuelle Gemeinschaft gestellt. Der Gesprächspartner sollte Angaben darüber machen, ob ihm diese Begriffe bekannt sind. Des Weiteren wurde hinterfragt, ob die Person bereits mit Programmen bzw. Webseiten aus diesen Themenbereichen zu tun hatte. 76

87 15. Entwicklung der Benutzeroberfläche 77 Abbildung 15.1: Altersstruktur. Abbildung 15.2: Computerkenntnisse laut eigenen Angaben.

88 15. Entwicklung der Benutzeroberfläche 78 Abbildung 15.3: Technisches Verständnis laut eigenen Angaben. Abbildung 15.4: Nutzungsdauer in Stunden pro Woche.

89 15. Entwicklung der Benutzeroberfläche 79 Abbildung 15.5: Struktur der Webapplikation. Mit Hilfe dieser Angaben wurde festgestellt, in wie weit die befragten Personen in Zusammenhang mit den definierten Zielgruppen gebracht werden können. Der letzte und größte Teil der Befragung beschäftigte sich mit dem entwickelten Benutzeroberflächenkonzept. Dabei wurden der befragten Person nacheinander die Entwürfe für die einzelnen Seiten gezeigt. Zu jeden Entwurf wurde die Person nach dem persönlichen Empfinden über die Übersichtlichkeit der Seite befragt. Außerdem sollte die Person angeben, ob die dargestellten Funktionen verständlich sind. Mögliche Probleme mit der Darstellung wurden hinterfragt und analysiert. Die Ergebnisse dieses Teils der Befragung sind folgend beschrieben. Ferner sind in den folgenden Abschnitten die Seitenentwürfe ausführlich kommentiert. Die Ergebnisse der Befragung sind in Form der ausgefüllten Fragebögen auf der DVD zu finden. Außerdem ist dort der leere Fragebogen als Vorlage für mögliche weitere Befragungen bereit gestellt Die Benutzeroberfläche im Allgemeinen Bevor in den nachfolgenden Abschnitten auf die einzelnen Seiten der Webapplikation eingegangen wird, widmet sich dieses Unterkapitel dem allgemeinen Aspekt der Benutzeroberfläche. Zum besseren Verständnis der Benutzeroberfläche wird zunächst die Verbindung der einzelnen Seiten untereinander erläutert. Des Weiteren wird das Gerüst, das jeder Seite zugrunde liegt, erklärt. Zuletzt weist dieser Abschnitt auf die Trennung von Konzept und Präsentation hin Struktur Abbildung 15.5 zeigt die Struktur der Benutzeroberfläche. In diesem Fall handelt es sich um eine Webapplikation. Die Webapplikation lässt sich in drei große Bereiche unterteilen: Main (Hauptfunktionen), Toolkit (Einspielen von Media Assets und Verwalten der Strukturen) und Administration (Benutzer- und Domänenverwaltung). Diese drei Bereiche werden als die erste Menüebene der Webapplikation abgebildet. Jeder dieser Menüpunkte verfügt über eine untergeordnete

90 15. Entwicklung der Benutzeroberfläche 80 Abbildung 15.6: Seitenaufbau: Eine Seite besteht aus Kopfbereich, Menü, Seiteninhalt und Fußzeile. Menüebene. Wie auf Abbildung 15.5 auf der vorherigen Seite zu sehen ist, beinhaltet das Menü Main die folgenden Unterseiten: Home, Assets, Advanced Search, Lightbox und Prepackagings. Jede dieser Unterseiten kann auf die anderen Unterseiten innerhalb des Menüs Main zugreifen. Außerdem haben alle Unterseiten dieses Menüs Zugriff auf die anderen Menüpunkte Toolkit und Administration. Für die Menüpunkte Toolkit und Administration sowie deren Unterseiten verhält es sich wie für den zuvor beschriebenen Menüpunkt Main Seitenaufbau Das Benutzeroberflächenkonzept sieht den in Abbildung 15.6 dargestellten Seitenaufbau vor. Dabei ist der Seiteninhalt in vier Bereiche unterteilt: Kopfbereich, Menü, Seiteninhalt und Fußzeile. Der detaillierte Aufbau sowie der Inhalt des Kopfbereiches wird in dem Abschnitt 15.4 näher beschrieben. Über das Menü ist in dem Abschnitt 15.5 eine ausführliche Beschreibung zu finden. Der eigentliche Seiteninhalt ist abermals unterteilt. Da diese Unterteilung jedoch variiert, gehen die Kapitel zu den einzelnen Seiten (ab Abschnitt 15.6) näher darauf ein. Der letzte Bereich auf der Seite ist die Fußzeile. Sie ist für die folgenden Informationen oder für Verlinkungen zu diesen vorgesehen: Impressum, Kontaktdaten, Urheberschutz und allgemeine Geschäftsbedingungen (AGB).

91 15. Entwicklung der Benutzeroberfläche 81 Abbildung 15.7: Benutzeroberflächenkonzept für den Webauftritt von gegenalltag: Das Hauptaugenmerk liegt auf der Anordnung der Benutzeroberflächenelemente Konzept Die hier vorgestellte Benutzeroberfläche ist als Konzept zu betrachten, welches die Anordnung von Inhalt und Bedienelementen sowie deren Funktionalität berücksichtigt. Für eine angemessene visuelle Präsentation der Webapplikation ist das Konzept durch einen Grafikdesigner zu überarbeiten. Der Unterschied zwischen Konzept und Grafikdesign soll anhand des Webauftritts von gegenalltag veranschaulicht werden. Während Abbildung 15.7 das Konzept für den Webauftritt von gegenalltag zeigt, wird auf Abbildung 15.8 auf der nächsten Seite das grafisch überarbeitete Konzept für diesen präsentiert. Während eines Berufspraktikums wurde der Webauftritt für gegenalltag neu gestaltet. Unter Berücksichtigung der Wünsche des Auftragsgebers wurde ein Konzept erstellt. Dieses diente zur Anordnung des Inhalts und zur Planung der Funktionalitäten unter Berücksichtung der technischen Möglichkeiten. Nach Rücksprache mit dem Auftraggeber wurde das Konzept zur Überarbeitung an eine Grafikdesignerin weitergeben. Durch deren professionelle Überarbeitung verlieh sie dem Konzept den grafischen Feinschliff und steigerte die Attraktivität des Webauftritts Registrierung und Anmeldung Sowohl für die Registrierung als auch für die Anmeldung bei TEAPOT wird die eigentliche Webseite verlassen. Dem Benutzer wird jeweils ein allein stehendes Formular, wie in Abbildung 15.9 auf Seite 83 und auf Seite 83 dargestellt, angezeigt. Die befragten Personen empfinden beide Formulare als übersichtlich und geben an, dass sie mit der Bedienung der

92 15. Entwicklung der Benutzeroberfläche 82 Abbildung 15.8: Benutzeroberflächendesign für den Webauftritt von gegenalltag: Das Design von Evelyn Eberhardt basiert auf dem Benutzeroberflächenkonzept (siehe Abbildung 15.7 auf der vorherigen Seite). Formulare zurechtkommen. Dass für die Registrierung bzw. für die Anmeldung bei TEAPOT die eigentliche Webseite verlassen wird, findet keine der befragten Personen als problematisch. Einige der Befragten betrachten dies als einen Vorteil, da nichts von dem Registrierungs- oder Anmeldungsprozess ablenkt. Das Verlassen der eigentlichen Webseite für die Anmeldung bei TEAPOT beurteilen zwei der befragten Personen zwar nicht als problematisch, dafür aber als störend. Die beiden Personen sind die Integration des Anmeldeformulars in die eigentliche Webseite gewohnt. Bei TEAPOT wäre eine Integration des Anmeldeformulars im Kopfbereich (siehe Abschnitt 15.4) der Webapplikation möglich. Das Logo dient der Zuordnung der Formulare zu der eigentlichen Webapplikation. Außerdem kann das Logo angeklickt werden. Dadurch wird der Benutzer auf die Startseite der Webapplikation zurückgeführt. Diese Funktionalität ist bereits Standard und wird von den meisten Befragten vorausgesetzt. Die Eingabefelder der hier abgebildeten Registrierung (siehe Abbildung 15.4 auf der nächsten Seite) sind als Beispiel zu betrachten. Die tatsächlich benötigten Felder ergeben sich aus den späteren Anforderungen von Seiten der Benutzerverwaltung.

93 15. Entwicklung der Benutzeroberfläche 83 Abbildung 15.9: Registrierung (englisch: register). Abbildung 15.10: Anmeldung (englisch: login) Kopfbereich Dieser Abschnitt setzt sich speziell mit dem Kopfbereich der Seite auseinander. In Abbildung auf der nächsten Seite und auf der nächsten Seite wird der Kopfbereich detailliert und abgekoppelt von dem restlichen Inhalt der Seite angezeigt. Linker Hand befindet sich im Kopfbereich das Logo. Dieses dient zur Wiedererkennung der Webseite. Außerdem kann es angeklickt werden und führt den Benutzer stets auf die Startseite der Webapplikation zurück. Die Platzierung des Logos ist immer gleich, sodass der Benutzer es gut sehen und finden kann. Rechts neben dem Logo befindet sich die Angabe der Domäne. In diesem Fall wird TEAPOT an der Fachhochschule Hagenberg eingesetzt. Der Name der Domäne lautet im Falle der Abbildungen auf der nächsten Seite und auf der nächsten Seite FH Hagenberg. Die Befragung ergab, dass eine Person mit dem Einsatz des At-Zeichen in der Domänenangabe nicht zurecht kommt. Da für alle anderen Befragten die Domänenangabe jedoch verständlich war, besteht hier kein Grund zu einer Änderung. Das Aussprechen des At- Zeichen als TEAPOT at FH Hagenberg erklärt dessen Bedeutung. Es wird hierfür allerdings vorausgesetzt, dass man das At-Zeichen als solches und nicht beispielsweise ausschließlich als Klammeraffe kennt. Ein angemeldeter Benutzer mit ausreichenden Rechten (z. B. Administrator) sieht die Domänenangabe wie in Abbildung auf der nächsten Seite. Über das Aufklappmenü kann zwischen den verfügbaren Domänen gewechselt werden. Es sind auf der

94 15. Entwicklung der Benutzeroberfläche 84 Abbildung 15.11: Kopfbereich der Webapplikation: Es ist kein Benutzer angemeldet. Abbildung 15.12: Kopfbereich der Webapplikation: Der Benutzer Patricia Kalina ist angemeldet. Webseite stets nur die Inhalte der gerade ausgewählten Domäne sichtbar. Rechter Hand findet sich auf der Seite eine einfache Suche. Gibt der Benutzer ein Schlagwort ein, werden der Name, die Beschreibung und die Schlagwörter aller Media Assets nach diesem Schlagwort durchsucht. Die Suche ist an dieser Stelle platziert um dem Benutzer stets das schnelle Suchen nach Media Assets zu ermöglichen. Auf Abbildung befinden sich oberhalb der einfachen Suche Verlinkungen zur Hilfe, Anmeldung und Registrierung. Auf Abbildung ist die Verlinkung zur Anmeldung bei TEAPOT (Login) durch die Verlinkung zur Abmeldung von TEAPOT (Logout) ersetzt. Die Verlinkung zur Registrierung (Register) ist durch den Namen des Benutzers ersetzt. Der Name des Benutzers ist verlinkt und führt ihn auf seine Profilseite, wo er Einstellungen und Daten ändern kann. Zwei der befragten Personen stören sich an dem Fragezeichen, das rechts neben der Verlinkung zur Hilfe (Help) steht. Da das Fragezeichen jedoch ein Standardsymbol für Hilfe ist, wurde es nicht aus dem Konzept entfernt. Insgesamt betrachtet empfinden alle befragten Personen den Kopfbereich dennoch als übersichtlich Menü Dieser Abschnitt widmet sich dem Menü der Webapplikation. Der Menüaufbau basiert auf der bereits zuvor beschriebenen Seitenstruktur (siehe Abschnitt ) und wird aus diesem Grund nicht weiter diskutiert. Vielmehr wird auf die Gestaltung der Menüführung eingegangen. Ferner wird die Markierung aktiver Seiten im Menü und das Piktogrammmenü in zwei weiteren Unterkapiteln detailliert behandelt Menüführung Um das Aussehen der Menüführung der Benutzeroberfläche zu begründen wird folgend die Herleitung des Menüs beschrieben. Abbildung auf der nächsten Seite zeigt die Menüführung der Onlinedemonstrationsversion von AssetBank. Es handelt sich hierbei um ein vertikales Menü. Positiv an diesem Menü ist die auffällige Markierung, die angibt, wo genau sich der Benutzer auf der Seite befindet. Des Weiteren ist der zusätzliche Kasten mit dem Titel My Lightbox (deutsch: Mein Leuchtkasten) eine gute Ergänzung. Der Leuchtkasten ist ein Werkzeug um Media Assets,

95 15. Entwicklung der Benutzeroberfläche 85 Abbildung 15.13: AssetBank: Menü der Onlinedemonstrationsversion. welche der Benutzer als brauchbar betrachtet, zu sammeln. Im Leuchtkasten können die gesammelten Media Assets später noch einmal angesehen und sortiert werden. Zusätzlich ist der Benutzer durch den extra angeführten Kasten My Lightbox ständig darüber informiert, wie viele Media Assets er bereits gesammelt hat. In Anlehnung an das Menü aus Abbildung ist für TEAPOT der Entwurf in Abbildung auf der nächsten Seite entstanden. Bei diesem Entwurf steht weniger die grafische Gestaltung als die Anordnung der Elemente im Vordergrund. Wie auch bei dem Vorbild ist hier die deutliche Markierung der Position auf der Seite wichtig. Auch die Idee des separaten Kastens für den Leuchtkasten wurde in den Entwurf übernommen. Für die Bereiche Toolkit und Administration sind in dem vertikalen Menü eigene Abschnitte angelegt. Beide Menübereiche sind mit einer Überschrift versehen, sodass die Abgrenzung zum Basismenü deutlich erkennbar ist. Die Sichtbarkeit der Menüblöcke ist abhängig von den Berechtigungen des Benutzers sowie davon, ob der Benutzer bei TEAPOT an- oder abgemeldet ist. Die Menüführung in Abbildung auf der nächsten Seite bietet den Vorteil, dass der Benutzer auf einen Blick all seine Möglichkeiten sehen kann. Es ist kein Durchsuchen von Menüeinträgen erforderlich. Ein Nachteil dieser Menüanordnung ist der Platz, den sie beansprucht. Besonders auf der Seite Assets (siehe Abschnitt 15.7) geht in der Breite der Platz für den Finder verloren. Aus diesem Grund fiel die Entscheidung, ein horizontales Menü einzusetzen. Abbildung auf der nächsten Seite zeigt die horizontale Menüführung des Content Management Systems Der Dirigent. Ähnlich zu diesem Beispiel gestaltet sich der erste Entwurf für eine horizontale Menüführung, wie es Abbildung auf Seite 87 zeigt. Ein in Abbildung auf der nächsten Seite identifizierter Mangel ist bei dem Entwurf für TEAPOT behoben. Bei der Menüführung von Der Dirigent kann der Benutzer nicht sagen, in welchem Bereich der Webseite er sich gerade befindet. Einem geübten Benutzer ist es unter Umständen möglich trotz fehlender Markierung seine Position auf der Webseite zu kennen. Dennoch widerspricht dies dem Prinzip Don t make me think! (deutsch: Bringe mich nicht zum Nachdenken!), das als oberste Regel der Benutzerfreundlichkeit von Steve Krug geprägt wird. Abbildung auf Seite 87 zeigt die verbesserte Variante für TEAPOT, in der durch Pfeile darauf hingewiesen wird, wo auf der Webseite sich der Benutzer gerade befindet.

96 15. Entwicklung der Benutzeroberfläche 86 Abbildung 15.14: TEAPOT: Entwurf für ein vertikales Menü in Anlehnung an das Menü der Onlinedemonstrationsversion von AssetBank (Abbildung auf der vorherigen Seite). Abbildung 15.15: Der Dirigent: Horizontales Menü im Backend.

97 15. Entwicklung der Benutzeroberfläche 87 Abbildung 15.16: TEAPOT: Entwurf für ein horizontales Menü. Abbildung 15.17: TEAPOT: Überarbeiteter Entwurf für ein horizontales Menü. Abbildung 15.18: Amazon: Horizontales Menü mit Karteireitern. Da der erste Entwurf für ein horizontales Menüs nicht komplett zufriedenstellend war, wurde dieser überarbeitet. Abbildung zeigt das Ergebnis der Überarbeitung des Entwurfs. Wie bereits bei dem Entwurf des vertikalen Menüs steht auch hier die Anordnung der Elemente im Vordergrund und nicht der grafische Aspekt. Der Entwurf in Abbildung trennt die einzelnen Menübereiche durch Karteireiter. Es ist deutlich zu sehen, welcher der Karteireiter gerade aktiv und welche Seite ausgewählt ist. Dem Benutzer ist es dadurch möglich seine genaue Position auf der Webseite zu kennen, was auch die Befragung der Personen bestätigt. Außerdem wurde durch die Anordnung des Menüs Platz gespart. Ähnlich zu dem in Abbildung dargestellten Menü verhält sich die Menüführung von Amazon in Abbildung Amazon ist einer der Vorreiter beim Einsatz von Menüführungen mit Karteireitern. Als eine der wenigen Webseiten setzt Amazon diese Art der Menüführung auch richtig ein [9, Seite 81]. Steve Krug beschreibt, was bei der Gestaltung eines Menüs mit Karteireitern zu beachten ist [9, Seite 82f]: Karteireiter müssen sich wie Karteireiter anfühlen. Neben der typischen Form ist es wichtig, dass der aktive Karteireiter im Kontrast zu den inaktiven Karteireitern steht. Des Weiteren muss der aktive Karteireiter mit dem zugehörigen Inhalt verbunden sein. Bei dem ersten Aufruf einer Webseite muss bereits ein Karteireiter ausgewählt sein. Dies ist wichtig um die Aufmerksamkeit des Benutzers auf den Einsatz von Karteireitern zu lenken. Karteireiter müssen auch ohne farbliche Kodierung funktionieren. Auch farbenblinde Menschen sollen in der Lage sein ein Karteireitermenü zu bedienen.

98 15. Entwicklung der Benutzeroberfläche 88 Abbildung 15.19: Amazon: Neue Menüführung seit Frühjahr Abbildung 15.20: Horizontales Menü: Der Pfeil ist links neben dem Menüobjekt platziert und zeigt in die entgegengesetzte Richtung. All diese Punkte wurden bei dem Entwurf für TEAPOT berücksichtigt und sind eine Auszeichnung für eine durchdachte Menüführung. Aus gegebenen Anlass muss an dieser Stelle darauf hingewiesen werden, dass Amazon im Frühjahr 2008 seine Menüführung geändert hat (siehe Abbildung 15.19). Amazon begründet die Änderung damit, dass sich die Anzahl der angebotenen Menüpunkte nicht mehr mit einem Karteireitermenü vereinbaren ließ. Da bei TEAPOT weitaus weniger Karteireiter benötigt werden, eignet sich hier das Karteireitermenü nach wie vor am besten Markierung einer aktiven Seite Das Menü in Abbildung auf der vorherigen Seite war Ausgangspunkt für die Befragung über die Benutzerfreundlichkeit der Benutzeroberfläche. Jeder der Befragten kann bei Betrachtung des Menüs in Abbildung auf der vorherigen Seite angeben, wo auf der Webseite er sich gerade befindet. Die meisten Befragten empfinden die Markierung der aktiven Seite jedoch als störend. Dabei stellt die Position des Pfeils sowie dessen Zeigerichtung ein Problem dar. Da die gewohnte Leserichtung in Europa von links nach rechts ist, zeigt der Pfeil in Abbildung in diese Richtung. Eine der befragten Personen bemängelt, dass die in Abbildung auf der vorherigen Seite und vorgeschlagene Markierung einer aktiven Seite sich nicht in das restliche Benutzeroberflächenkonzept einfügt. Aus diesem Grund präsentiert Abbildung auf der nächsten Seite einen Vorschlag für eine besser passende Markierung. Ein anderer Kritikpunkt, der von einer der befragten Personen geäußert wurde, ist die

99 15. Entwicklung der Benutzeroberfläche 89 Abbildung 15.21: Horizontales Menü: Der Pfeil und der Unterstrich wurden durch eine graue Hinterlegung ersetzt. Abbildung 15.22: Horizontales Menü: Zusätzlich zu der grauen Hinterlegung werden die Menüobjekte durch vertikale Striche getrennt. Abbildung 15.23: Piktogrammmenü: Ein Haus als Symbol für Home, eine Lupe als Symbol für Advanced Search und ein Ordner als Symbol für Lightbox. mangelnde optische Trennung der Menüobjekte. Da manche Menüobjekte aus mehr als einem Wort bestehen (z. B. Advanced Search), ist eine eindeutige Trennung der Menüobjekte nicht möglich. In Abbildung ist dieser Mangel behoben. Da Abbildung alle Kritikpunkte der Befragten berücksichtigt, ist diese Menüführung auch Bestandteil des endgültigen Benutzeroberflächenkonzepts Piktogrammmenü Im Menübereich der Webseite (siehe Abschnitt auf Seite 80) befindet sich rechter Hand ein Piktogrammmenü. Mit Hilfe dieses Menüs soll der Benutzer jederzeit auf die Startseite zurückkehren oder auf die Schlüsselfunktionen der Webseite zugreifen können. Abbildung zeigt dieses Piktogrammmenü. Die Piktogramme haben von links nach rechts betrachtet die folgende Bedeutung: Home, Advanced Search und Lightbox. Für die befragten Personen war die Bedeutung der Piktogramme zum Teil schwer zu erraten. Während die Befragten den ersten beiden Piktogrammen die richtige Bedeutung zuordnen konnten, hatten sie bei dem dritten Piktogramm Schwierigkeiten. Das Haus ist ein Standardsymbol für die Startseite und die Lupe ist ein Standardsymbol für die Suche. Das dritte Symbol ist für die befragten Personen als Ordner zu erkennen, aber nicht zu einer Funktion zuzuordnen. Dies liegt zum einen daran, dass der Ordner nicht eindeutig mit dem Leuchtkasten in Verbindung gebracht werden kann. Zum anderen war manchen der befragten Personen die Funktion des Leuchtkastens unbekannt. Um den Benutzern der Webapplikation die Bedeutung des dritten Piktogramms näher zu bringen, ist das Piktogramm in die Menüführung eingebunden (siehe Abbildung auf der nächsten Seite). Dass die Findung eines Symbols für den Leuchtkasten nicht leicht ist, zeigen auch existierende Lösungen. Abbildung auf der nächsten Seite zeigt die von GettyImages einge-

100 15. Entwicklung der Benutzeroberfläche 90 Abbildung 15.24: Horizontales Menü: Zum besseren Verständnis des Icons für Lightbox wurde es in das Menü aufgenommen. Abbildung 15.25: GettyImages: Unterhalb jedes Bildes befindet sich ein Piktogrammmenü. Die Bedeutungen der Piktogramme von links nach rechts sind: dem Einkaufswagen hinzufügen, dem Leuchtkasten hinzufügen, den Preis des Bildes berechnen und ähnliche Bilder suchen. Abbildung 15.26: Corbis: Im Gegensatz zu GettyImages (siehe Abbildung 15.25) verzichtet Corbis auf den Einsatz eines Piktogrammmenüs. setzten Piktogramme. Das zweite Piktogramm von links steht hier für das Hinzufügen eines Media Assets zu dem Leuchtkasten. Diese Information ist aus dem von GettyImages gewählten Piktogramm jedoch nicht klar ersichtlich. Erst durch das Bewegen des Mauszeigers über das Piktogramm erscheint ein Informationstext, der diese Bedeutung erläutert. Im Gegensatz zu GettyImages verzichtet Corbis auf den Einsatz von Piktogrammen (siehe Abbildung 15.26). Für das Hinzufügen eines Media Assets zu einem Leuchtkasten wird der Text Lightbox (deutsch: Leuchtkasten) verwendet. Rechts neben dem Text befindet sich ein Kästchen. Dieses Kästchen ist leer, solange das Media Asset nicht einem Leuchtkasten hinzugefügt wird. Ist das Media Asset in einem Leuchtkasten enthalten, ist das Kästchen mit einem Häkchen gefüllt. Der Einsatz von Text wirkt dem Problem des Erratens von Piktogrammbedeutungen entgegen. Ist der Benutzer jedoch nicht mit dem Konzept des Leuchtkastens vertraut, schafft auch Text keine Klarheit für den Benutzer Startseite Der Inhalt der Startseite (siehe Abbildung auf der nächsten Seite) ist in zwei Spalten angeordnet. In der linken Spalte befindet sich ein Willkommenstext, der beispielsweise für

101 15. Entwicklung der Benutzeroberfläche 91 Abbildung 15.27: Startseite der Webapplikation: Der Benutzer Patricia Kalina ist angemeldet. eine kurze über die Webapplikation genutzt werden kann. Unter dem Willkommenstext wird ein angemeldeter Benutzer über für ihn hinterlegte Zusammenstellungen (englisch: prepackagings) benachrichtigt. Unter einer Zusammenstellung wird ein Leuchtkasten verstanden, der von einem anderen Benutzer zur Verfügung gestellt wird. Die Zusammenstellung kann heruntergeladen werden oder aber zur weiteren Bearbeitung wieder in einen Leuchtkasten umgewandelt werden. Zuunterst befindet sich in der linken Spalte ein Suchfeld. Dieses Suchfeld hat die gleiche Funktion wie das Suchfeld im Kopfbereich der Webseite (siehe Abschnitt 15.4). Es wird an dieser Stelle noch einmal angeboten um den Benutzer auf die zentrale Funktion des Media Asset Management Systems, das Suchen, hinzuweisen. Möchte der Benutzer genauer nach Media Assets suchen, findet er rechts neben den Suchfeld eine Verlinkung zur erweiterten Suche (Advanced Search). In der rechten Spalte sind zwei Blöcke untergebracht. Der obere Block enthält die zuletzt eingespielten Media Assets (Latest Items) und dient zur Information des Benutzers. Der untere Block enthält eine zufällige Auswahl an Media Assets (Random Items) und dient zur Inspiration des Benutzers. Auf der Startseite in Abbildung werden in der rechten Spalte ausschließlich Bilder angezeigt. Da mit TEAPOT aber auch Audiodateien, Dokumente, dreidimensionale Modelle und Videos verwaltet werden können, empfiehlt sich Darstellung der Media Assets wie in

102 15. Entwicklung der Benutzeroberfläche 92 Abbildung 15.28: Darstellung für die zuletzt hinzugefügten und zufällig ausgewählten Media Assets. Abbildung Dabei wird für Audiodateien und Dokumente ein Platzhalterbild eingesetzt, über das der Dateiname des Media Assets gelegt wird. Für Bilder, dreidimensionale Modelle und Videos werden Bildausschnitte der Originaldateien eingesetzt. Alle Darstellungen der Media Assets werden zusätzlich mit einem Piktogramm versehen, welches auf ihren Medientyp hinweist. Die befragten Personen empfinden die Startseite (siehe Abbildung auf der vorherigen Seite) als übersichtlich und sind weitgehend mit den angebotenen Funktionen vertraut. Die Mehrheit der Befragten erwartet, dass bei einem Klick auf ein Media Asset in der rechten Spalte die Detailansicht (siehe Abschnitt 15.10) zu dem Media Asset geöffnet wird. Ein Teil der befragten Personen wünscht sich auf der Startseite zusätzliche Funktionen. Es wurde unter anderem der Wunsch nach einem Block geäußert, der die von einem Benutzer zuletzt angesehenen Media Assets beinhaltet. Funktionen wie diese können für die Erweiterung von TEAPOT herangezogen werden Assets In Abbildung auf der vorherigen Seite wird die Seite Assets präsentiert. Sie enthält den Finder für die Media Assets. Der Benutzer hat mit Hilfe des Finders die Möglichkeit Kategorien (englisch: categories), Mediengruppen (englisch: mediagroups) und Schlagwörter (englisch: keywords) zu durchsuchen. Der Seiteninhalt ist in zwei Spalten angeordnet. In der linken, schmäleren Spalte befindet sich der bereits zuvor angesprochene Finder. Das Aussehen und die Funktionsweise des Finders ähnelt dem unter Windows gebräuchlichen Dateifinder. Die anzuzeigende Menge der Media Assets passt sich an die Auswahl im Finder an. Die Media Asset werden in der rechten, breiteren Spalte der Seite angezeigt. Dabei kann die Anzeige der Media Assets mit Hilfe der Karteireiter nach Medientyp eingeschränkt werden. Außerdem kann der Benutzer entscheiden, ob die Media Assets in einer Liste (siehe Abbildung auf der nächsten Seite) oder in einer Leuchttischdarstellung (siehe Abbildung auf Seite 97) angezeigt werden. Für die Auswahl der Ansicht stehen die beiden Piktogramme in der Verlängerung der Karteireiter zur Verfügung. Die befragten Personen erwarten, dass die Bilder im Anzeigefenster angeklickt werden können. Bei einem Klick auf ein Bild wird außerdem erwartet, dass sich die Detailansicht des Media Assets öffnet. Dieses Verhalten ist in dem Benutzeroberflächenkonzept vorgesehen. Eine der befragten Personen regt zusätzlich an, dass die Bilder vergrößert dargestellt werden, wenn der Mauszeiger darüber bewegt wird. Die Seitenumblätterfunktion ist den befragten Personen bekannt und sie verstehen deren Funktionsweise. Dennoch sind die Befragten mit der Standardumblätterfunktion nicht zufrie-

103 15. Entwicklung der Benutzeroberfläche 93 Abbildung 15.29: Finderseite der Webapplikation: Der Benutzer Patricia Kalina ist angemeldet. den. Da diese Unzufriedenheit jedoch nicht unmittelbar mit dem Benutzeroberflächenkonzept für TEAPOT in Zusammenhang steht, wurde die Optimierung der Seitenumblätterfunktion nicht weiter forciert. Lediglich die fehlende Angabe, auf welcher Seite von wie viel anzuzeigenden Seiten sich ein Benutzer befindet, wurde in dem Konzept ergänzt. Eine der befragten Person kritisierte, dass in dem Anzeigefenster für alle Media Assets der Medientyp eines Media Assets nicht ersichtlich ist. Dieser Mangel wurde behoben, indem im Beschreibungsfeld jedes Media Assets rechts oben der Medientyp angeführt ist. Des Weiteren stört einige der befragten Personen die Bildlaufleiste in dem Anzeigefenster. Diese ist jedoch nach wie vor erhalten, da die Anzahl der anzuzeigenden Media Assets pro Seite variieren kann. Der Benutzer kann in seinen Profileinstellungen angeben, wie viele Media Assets ihm pro Seite angezeigt werden sollen. Benötigen die anzuzeigenden Media Assets in der Höhe mehr Platz als das Anzeigefenster zur Verfügung stellt, wird die Bildlaufleiste aktiv. Insgesamt wird die Seite Assets von den befragten Personen als übersichtlich empfunden und die Funktionalitäten verstanden.

104 15. Entwicklung der Benutzeroberfläche Erweiterte Suche Die erweiterte Suche (Advanced Search) ist eine Schlüsselstelle des Media Asset Management Systems. Aus diesem Grund muss der Benutzerfreundlichkeit dieser Seite besondere Aufmerksamkeit geschenkt werden. Die erweiterte Suche bietet die folgenden Suchoptionen an: Search All, Search Audio, Search Document, Search Image, Search Model und Search Video. Search All ermöglicht eine Suche über die gemeinsamen Metadatenfelder aller Media Assets. Mit Hilfe von Auswahlkästchen kann das Suchergebnis dennoch auf bestimmte Medientypen eingeschränkt werden. Standardmäßig ist kein bestimmter Medientyp ausgewählt, wodurch keine Einschränkung des Suchergebnisses erfolgt. Diese Suchoption ist jedoch nicht dargestellt. In Abbildung auf der nächsten Seite wird stellvertretend für die medientypspezifischen Suchen die erweiterte Suche nach Bildern präsentiert. Wie bei der Suchoption Search All können auch für diese Suche zunächst beliebige Schlagwörter angegeben werden. Ferner werden Eingabefelder für alle Metadaten eines Bildes zum Ausfüllen angeboten. Außerdem kann der Benutzer seine Suche auf bestimmte Kategorien und Mediengruppen einschränken. Da fast keine der befragten Personen die Auswahl von Kategorien oder Mediengruppen für die erweiterte Suche verstanden hat, beinhaltet das endgültige Konzept Hinweise für die Verwendung der Suche. Eine andere Anordnung der Elemente ist aus Platzgründen nicht möglich. Mit dem System des Auf- und Zuklappen der Suchblöcke sind die befragten Personen weitgehend vertraut. Alle Befragten erwarten, dass ein Suchblock sich schließt, sobald ein andrer Suchblock geöffnet wird. Diese Erwartungshaltung wird zum einen dadurch unterstützt, dass jeder Suchblock mit den Schaltflächen Reset (deutsch: zurücksetzen) und Search (deutsch: suchen) ausgestattet ist. Zum anderen unterstützen die fehlenden Zeichen für das Auf- und Zuklappen der Suchblöcke in den Titelbalken diese Erwartungshaltung. Um dem Benutzer dennoch zu verdeutlichen, dass sich hinter den Titelbalken ein Suchblock verbirgt, ist beim Aufruf der Suchseite stets der Suchblock Search All geöffnet. Bei der Befragung erwartet die Mehrheit, dass das Ergebnis der Suche in einer eigenen Ergebnisseite (siehe Abbildung auf Seite 96) geöffnet wird. Dabei soll die soeben abgesetzte Suche verfeinert werden können. In der linken Spalte der Ergebnisseite wird die abgesetzte Suche noch einmal angezeigt. In den Eingabefeldern werden die zuvor angegebenen Suchpbegriffe nochmals ausgegeben. Im Anzeigefenster in der rechten Spalte werden die gefunden Media Assets dargestellt. Das Verhalten des Anzeigefensters deckt sich mit dem des Anzeigefensters der Seite Assets (siehe Abschnitt 15.7) Leuchtkasten Der Leuchtkasten (Lightbox) für die Webapplikation TEAPOT wird in Abbildung auf Seite 97 dargestellt. Dabei gleicht das Anzeigefenster für die Media Assets dem Anzeigefenster auf der Seite Assets (siehe Abschnitt 15.7). Der einzige Unterschied ist, dass die Darstellung der Media Assets im Leuchtkasten nicht nach Medientypen unterschieden werden kann. In Abbildung auf Seite 97 wird die Leuchttischdarstellung, die zweite angebotene Darstellungsform, vorgestellt. Hier wird die Information über den Medientyp eines Media Assets in der Ecke links unten angezeigt. Dabei ist der Anfangsbuchstabe des Medientyps als Großbuchstabe eingerahmt. Das Menü links vom Anzeigefenster besteht aus drei Blöcken. Die beiden Menüblöcke Toolkit und Download beziehen sich stets auf den aktiven Leuchtkasten. Einzige

105 15. Entwicklung der Benutzeroberfläche 95 Abbildung 15.30: Erweiterte Suchseite der Webapplikation: Der Benutzer Patricia Kalina ist angemeldet. Ausnahme ist der Menüpunkt New Lightbox des Menüblocks Toolkit. Dieser ist zum Anlegen neuer Leuchtkästen vorgesehen. Sonst hat der Benutzer die Möglichkeit den aktiven Leuchtkasten zu löschen oder ihn als Zusammenstellung für einen anderen Benutzer zu speichern. Was unter einer Zusammenstellung verstanden werden kann, wird kurz in Abschnitt 15.6 erläutert. Der Menüblock Download bietet dem Benutzer die Möglichkeit den Leuchtkasten als Archiv herunterzuladen. Unter erweiterten Download (englisch: Advanced Download) kann der Benutzer vor dem Herunterladen der Media Assets unter anderem entscheiden, welche Auflösung diese haben sollen. In dem untersten Menüblock Lightboxes sind alle verfügbaren Leuchtkästen aufgelistet. Der aktive Leuchtkasten ist in diesem Menüblock grau hinterlegt und mit einem kleinen Pfeil versehen, der in Richtung Anzeigefenster deutet. Der Inhalt des aktiven Leuchtkastens wird im Anzeigefenster dargestellt. Für die Bearbeitung eines Leuchtkastens ist kein separater Menüpunkt geplant. Der Name des Leuchtkastens kann direkt über dem Anzeigefenster geändert werden. Der Benutzer klickt auf die Schaltfläche Rename (deutsch: umbennen) und der Name erscheint zur Bearbeitung in einem Eingabefeld. Um Media Assets aus dem Leuchtkasten zu entfernen, verfügt jedes Media Asset über die Option Remove from Lightbox (deutsch: aus dem Leuchtkasten entfernen). Der Großteil der Befragten empfindet diese Seite als übersichtlich. Zunächst waren einige

106 15. Entwicklung der Benutzeroberfläche 96 Abbildung 15.31: Erweiterte Suche der Webapplikation: Suchergebnis. der befragten Personen nicht mit der Menüanordnung einverstanden, weshalb diese geändert wurde. Zuvor war die Liste der verfügbaren Leuchtkästen der oberste Menüblock. Da jedoch die Bearbeitung eines Leuchtkastens im Vordergrund steht, wurde den beiden Menüblöcken Toolkit und Download Vorrang gegeben. Eine der befragten Personen regte unabhängig von der in Abbildung auf der nächsten Seite dargestellten Seite an, dass in dem System stets ein Standardleuchtkasten vorhanden sein soll. Fügt ein Benutzer in TEAPOT erstmalig ein Media Asset einem Leuchtkasten hinzu, soll er die Möglichkeit haben den Standardleuchtkasten umzubenennen oder einen weiteren Leuchtkasten anzulegen. Sind für den Benutzer mehrere Leuchtkästen vorhanden, soll er stets selbst entscheiden, welchem davon das Media Asset hinzugefügt werden soll. Abbildung auf Seite 98 zeigt lediglich das Menü der Seite Prepackagins (deutsch: Zusammenstellungen), da dies der einzige Unterschied zur Seite Lightbox ist. Die befragten Personen haben sich über diese Seite nicht anders als über die Seite Lightbox geäußert.

107 15. Entwicklung der Benutzeroberfläche 97 Abbildung 15.32: Leuchtkästen für die Webapplikation: Der Benutzer Patricia Kalina ist angemeldet Detailansicht Abbildung auf Seite 99 zeigt die Detailansicht eines Media Assets. Hat der Benutzer die entsprechenden Rechte, werden ihm die detaillierten Informationen zu dem Media Asset bereits im Bearbeitungsmodus angezeigt. Auf diese Weise kann der Benutzer die bestehenden Informationen einsehen und gleichzeitig aktualisieren. Wie auf den anderen Seiten ist auch hier der Bereich Seiteninhalt in zwei Spalten angeordnet. In der linken Spalte wird das Media Asset, in diesem Fall ein Bild, vergrößert dargestellt. Darunter befindet sich der Befehl zum Herunterladen des Media Assets sowie die Möglichkeit das Media Asset in Originalgröße anzusehen. Des Weiteren kann der Benutzer das Media Asset einem Leuchtkasten hinzuzufügen. Wenn es sich bei dem darzustellenden Media Asset um eine Audiodatei oder ein Video handelt, wird anstelle des vergrößerten Bildes ein Abspielgerät für Video- und Audiodateien eingebunden. Bei Videodateien wird zum Abspielen eine geringere Auflösung verwendet. Zusätzlich werden unterhalb des Abspielgerätes einige Stillbilder aus der Videodatei angezeigt. Handelt es sich bei dem Media Asset um ein Dokument, wird anstelle eines vergrößerten Bildes ein Textausschnitt vom Dokumentbeginn angezeigt. In der rechten Spalte werden die zuvor erwähnten detaillierten Informationen über das Bild ausgegeben. Dabei wird hier ebenso das Prinzip des Auf- und Zuklappens für die einzelnen Informationsblöcke angewandt (vgl.

108 15. Entwicklung der Benutzeroberfläche 98 Abbildung 15.33: Zusammentstellungen für die Webapplikation: Das Menü ist der einzige Unterschied zu Abbildung auf der vorherigen Seite. Abschnitt 15.8 auf Seite 94). Im Gegensatz zu der erweiterten Suche erwarten die befragten Personen in der Detailansicht jedoch, dass sich ein Block beim Öffnen eines anderen Blockes nicht automatisch schließt. Die Balken enthalten ein Plus- oder Minussymbol, welches dieses Verhalten kennzeichnet. Außerdem befinden sich die Befehle zum Zurücksetzen (Reset) oder Speichern (Save) der Informationen einmalig unterhalb der Informationsblöcke und nicht in jedem Block extra. Links unterhalb der Informationsblöcke befindet sich der Befehl zum Löschen des Media Assets (Delete). Dieser war zuvor oberhalb der Informationsblöcke angeordnet. Die befragten Personen erachteten diese Anordnung jedoch nicht als schlüssig. Die Platzierung des Löschbefehls unterhalb der Informationsblöcke in einer Reihe mit den anderen Befehlen ist für die befragten Personen klarer. Der Befehl ist jedoch links abgesetzt von allen anderen Befehlen angeordnet, sodass ein unabsichtliches Löschen durch den Benutzer vermieden wird. Wenn der Benutzer den Befehl zum Löschen eines Media Assets ausführt, so wird er zuvor noch einmal gefragt, ob er diese unwiderrufliche Aktion tatsächlich ausführen möchte. Durch diese Rückfrage wird die Möglichkeit eines unabsichtlichen Löschens weiter minimiert. Ingesamt haben alle befragten Personen die Seite als übersichtlich empfunden. Die befragten Personen sind auch mit den angebotenen Funktionalitäten vertraut. Für die Detailansicht standen drei Optionen zur Verfügung: Die Umsetzung als ein Popupfenster, als eine eigene Unterseite oder als Fenster, dass sich über die aktuell geöffnete Seite legt. Die Darstellung der Detailansicht in einer eigenen Unterseite erschien unpassend, da jedes Mal nach Beenden der Detailansicht beispielsweise die Seite Assets neu geladen werden müsste. Aufgrund der häufig eingesetzten Popup-Blocker fiel die Entscheidung dann auf die Umsetzung als Fenster, dass sich über die aktuell geöffnete Seite legt und die Detailansicht enthält. Dabei wird der Hintergrund ausgegraut und inaktiv. Dieses Fenster kann entweder

109 15. Entwicklung der Benutzeroberfläche 99 Abbildung 15.34: Detailansicht eines Media Assets: Der Hintergund ist augegraut und inaktiv. über den Befehl zum Schließen (Close) rechts oben oder über den Befehl zum Speichern (Save) geschlossen werden. Bei der Ausführung des Befehls zum Speichern werden vor dem Schließen etwaige Änderungen übernommen. Entscheidet sich der Benutzer für das Löschen des Assets, wird die Detailansicht geschlossen und das Asset aus dem Media Asset Management System entfernt Einspielen von Media Assets Die Abbildung Einspielen von Media Assets: Ein Archiv mit mehreren Media Assets wurde eingespielt und steht zur weiteren Bearbeitung bereit. zeigt die Seite für das Einspielen der Assets. Diese Seite ist vordergründig dazugedacht, dass der Benutzer einfach und schnell Media Assets ortunabhängig (beispielsweise außerhalb der Firma von zu Hause) einspielen kann. Für den Firmenbetrieb ist später ein Massenimporter vorgesehen, der als Desktopapplikation umgesetzt werden wird. Auf Abbildung wird das Aussehen der Seite nach dem Einspielen eines Archivs dargestellt. Dabei öffnet sich ähnlich der Seite Assets eine Ansicht mit den neu eingespielten Media Assets. Die neu eingespielten Media Assets werden standardmäßig in der Kategorie Unkategorisiert abgelegt. Dadurch kann der Benutzer die unbearbeiteten Media Assets auch

110 15. Entwicklung der Benutzeroberfläche 100 Abbildung 15.35: Einspielen von Media Assets: Ein Archiv mit mehreren Media Assets wurde eingespielt und steht zur weiteren Bearbeitung bereit. nach Verlassen der Seite Upload sofort finden. In dem grauen Kasten links wird der Benutzer auf diese Möglichkeit hingewiesen. Jedes Media Asset mit einem Link zum Bearbeiten (Edit) versehen, damit der Benutzer die Metadaten des Media Assets bearbeiten kann. Die restlichen Funktionen decken sich mit dem Anzeigefenster der Seite Assets (siehe Abschnitt 15.7). Es fehlt hier lediglich die Wahl der Darstellungsform (Liste oder Leuchttischdarstellung), weil zu diesem Zeitpunkt noch keine Beschreibung des Media Assets vorhanden ist. Die befragten Personen empfinden die Seite als übersichtlich und kommen mit den Funktionalitäten zurecht Verwaltung von Strukturen Im Bereich Toolkit können neben dem Einspielen von Media Assets auch die im Media Asset Management System angebotenen Strukturen verwaltet werden (siehe Abbildung auf Seite 102). Zu den Strukturen zählen: Keyword (deutsch: Schlagwort), Category (deutsch: Kategorie), Mediagroup (deutsch: Mediengruppe) und Mediagrouptype (deutsch: Mediengruppentyp). Eine Erläuterung zu den Strukturen ist in Kapitel 7 zu finden. Der Seiteninhalt für die Verwaltung der Strukturen ist für alle Verwaltungsseiten gleich

111 15. Entwicklung der Benutzeroberfläche 101 aufgebaut. Es sind zwei Spalten, wobei die Rechte in einen oberen und unteren Block unterteilt ist. In der linken Spalte werden dem Benutzer die verfügbaren Elemente angezeigt. In dem rechten oberen Block hat der Benutzer die Möglichkeit neue Elemente anzulegen. Im rechten unteren Block hat der Benutzer die Möglichkeit, das in der linken Spalte aktuell ausgewählte Element zu bearbeiten. Wechselt der Benutzer von einer anderen Seite auf eine Verwaltungsseite, ist standardmäßig das erste Element der verfügbaren Elemente ausgewählt und wird in dem Bearbeitungsbereich dargestellt. Dies ist notwendig, damit dem Benutzer sofort der Zusammenhang zwischen der Auswahl und dem Bearbeitungsbereich klar wird. Die befragten Personen haben alle kein Problem den Zusammenhang zu erkennen, wenn links eine Auswahl markiert ist. Erstellt der Benutzer ein neues Element, so wird dieses in der Liste der verfügbaren Elemente hinzugefügt und sofort markiert. Bei einem Klick auf die Schaltfläche OK wird das Element mit den ersten angegeben Informationen bereits gespeichert. Mit dem Befehl zum Speichern (Save) werden die Änderungen, die in der Bearbeitungsbox vorgenommen wurden, gespeichert. Der Benutzer wird durch eine Rückmeldung des System über den erfolgreichen Abschlusses des Speicherns informiert. Der Bearbeitungsbereich bleibt geöffnet. Mit einem Klick auf die Schaltfläche Reset (deutsch: zurücksetzen) können nicht gespeicherte Änderungen zurückgesetzt werden. Löscht der Benutzer ein Element, wird er vor der endgültigen Ausführung des Befehls noch einmal gefragt, ob er das Element tatsächlich löschen will. Entscheidet sich der Benutzer für das Löschen, wird das Element entfernt und die Markierung des Elements in der Liste aller verfügbaren Elemente springt auf das nächste Element. Stellvertretend für alle Verwaltungsseiten wird in Abbildung auf der nächsten Seite die Verwaltung von Mediengruppen (englisch: mediagroups) vorgestellt. Die Verwaltung der Mediengruppen war für die befragten Personen die problematischste Seite und wird aus diesem Grund näher erläutert. Für das Verständnis dieser Seite muss das Mediengruppenkonzept bekannt sein. Dieses wird näher in Kapitel 7 erläutert. Nach der Verinnerlichung des Konzepts ist auch die Menüreihenfolge verständlich: Der Menüpunkt Mediagrouptype kommt vor dem Menüpunkt Mediagroup. Für die Erstellung einer Mediengruppe ist die Angabe eines Mediengruppentyps, von dem der Benutzer zumindest einen vorher selber angelegt haben muss, verpflichtend. Aus diesem Grund ist in dem Erstellungsbereich ein Aufklappmenü vorhanden, in welchem der Benutzer einen bestehenden Typ auswählen muss. Das Aufklappmenü wird allerdings erst aktiv, sobald der Benutzer beginnt einen Namen für eine neue Mediengruppe einzugeben. Hat der Benutzer für die neu erstellte Mediengruppe einen Mediengruppentyp ausgewählt, der nicht der ersten Ebene der Hierarchie von Medientypen angehört, muss der Benutzer eine Mediengruppe mit einem übergeordneten Mediengruppentyp auswählen. Tritt dieser Fall ein, wird das Aufklappmenü mit dem Titel Mediagroup for selected Type aktiv. Erst durch die Auswahl einer Mediengruppe mit einem übergeordneten Medientyp ist die richtige Einordnung der neu erstellten Mediengruppe in die Hierarchie möglich. Abbildung auf der nächsten Seite soll diese Vorgehensweise veranschaulichen. Alle Benutzer können die Beschreibung des Mediangruppenkonzeptes inklusive einem Beispiel mit einem Klick auf das Informationsfeld abrufen. Insgesamt empfinden die befragten Personen die Verwaltungsseiten als übersichtlich. Etwaige Probleme wurden unter anderem durch die Änderung der Anordnung der Schaltflächen sowie die Umstellung auf eine horizontale Schlagwortzuordnung behoben. Die weiteren Veränderungen sind bei dem Vergleich der Abbildung auf der nächsten Seite und Abbildung auf Seite 103 ersichtlich. Das Konzept für alle weiteren Verwaltungsseiten (Keyword, Category und Mediagrouptype) sind der DVD zu entnehmen.

112 15. Entwicklung der Benutzeroberfläche 102 Abbildung 15.36: Verwaltung von Strukturen: Diese Seite dient der Verwaltung von Mediengruppen (englisch: mediagroups). Abbildung 15.37: Hinzufügen und Einordnen einer neuen Mediengruppe.

113 15. Entwicklung der Benutzeroberfläche 103 Abbildung 15.38: Verwaltung von Strukturen: Dies ist das Konzept für die Verwaltung von Mediengruppen vor der Überarbeitung Administration Die Benutzerverwaltung ist zwar Bestandteil der Benutzeroberfläche, aber zum jetzigen Zeitpunkt nur als eine Empfehlung zu betrachten. Der Grund dafür ist, dass in der Serverimplementierung im Moment noch keine Benutzerverwaltung vorhanden ist und die konkreten Bedürfnisse der Benutzerverwaltung nicht erhoben wurden. Eine Ausnahme ist die Darstellung für die Verwaltung von Domänen, da das Domänenkonzept bereits serverseitig berücksichtigt wird. Mit der Abbildung auf der nächsten Seite wird dennoch versucht einen brauchbaren Vorschlag für die Benutzerverwaltung abzugeben, der konzeptuell zu der restlichen Oberfläche passt. Auch hier verhält sich der Seitenaufbau und die Funktionen wie für die Verwaltung der Strukturen (siehe Abschnitt 15.12). Es ist lediglich hinzuzufügen, dass es im Bearbeitungsbereich zur Zeit eine Schaltfläche gibt, die es dem Benutzer erlaubt zusätzliche Informationen zu einem Benutzer anzuzeigen (z. B. Profileinstellungen oder Notizen zu dem Benutzer). Für die Darstellung der zusätzlichen Informationen soll ähnlich der Detailansicht (siehe Abschnitt 15.10) ein Fenster über die aktuelle Seite gelegt werden. Der Hintergrund soll dabei ausgegraut und inaktiv werden. Auch für die Seiten der Administration gilt, dass sie von den befragten Personen als über-

114 15. Entwicklung der Benutzeroberfläche 104 Abbildung 15.39: Administration: Diese Seite dient der Verwaltung von Benutzern. sichtlich empfunden werden. Die Funktionalitäten sind den befragten Personen klar. Selbst jene befragten Personen, die kaum in Berührung mit einer Benutzerverwaltung kommen, finden sich zurecht. Das in dem Benutzeroberflächenkonzept vorgeschlagene Berechtigungssystem sieht vor, dass Gruppen mit beliebigen Kombinationen von Rechten erstellt werden können. Dabei schließen die Berechtigungen beispielsweise auch die Sichtbarkeit von Kategorien und Mediengruppen ein. Einer Gruppe können beliebig viele Benutzer zugeordnet werden. Ein Benutzer kann ebenso mehreren unterschiedlichen Gruppen angehören, solange die definierten Gruppenrechte nicht widersprüchlich sind. Die Diskrepanzen in der ehemaligen Abbildung der Rechte sind in den aktuellen Entwürfen behoben. Zuvor sah das Benutzeroberflächenkonzept vor, dass eine Gruppe und ein Benutzer mit einer beliebigen Kombination von Rechten versehen werden kann. Zusätzlich galt, dass der Benutzer auch unterschiedlichen Gruppen zugewiesen werden kann. Ein Konzept wie dieses führt zwangsläufig zu Problemen in der Abbildung der Rechte, da leicht Widersprüche in der Rechtsvergabe entstehen können. Zum Vergleich mit dem neuen Berechtigungssystem wird in Abbildung auf der nächsten Seite der Entwurf mit dem ehemaligen Konzept dargestellt. Das aktuelle Konzept für die weiteren Verwaltungsseiten (Groups und Domains) sind der DVD zu entnehmen.

115 15. Entwicklung der Benutzeroberfläche 105 Abbildung 15.40: Administration: Dies ist das Konzept für die Verwaltung von Mediengruppen vor der Überarbeitung.

116 Kapitel 16 Evaluierung der Benutzeroberfläche In Abbildung 16.1 auf der nächsten Seite ist der Kriterienkatalog für die objektive Evaluierung des in dem vorangehenden Kapitel vorgestellten Benutzeroberflächenkonzepts dargestellt. In diesem Kriterienkatalog wird nicht nur die Erfüllung der Kriterien beurteilt, sondern auch die Priorität der Kriterienerfüllung. Links oben in Abbildung 16.1 auf der nächsten Seite wird die Bedeutung der verwendeten Prioritätsstufen und Symbole erläutert. Wie die Auflistung in Abbildung 16.1 auf der nächsten Seite zeigt, kann ein Großteil der Kriterien erfüllt werden. Im Anschluss befindet sich eine detaillierte Interpretation und Diskussion des Evaluierungsergebnisses. Die Erläuterungen der Heuristiken können im Abschnitt zum besseren Verständnis der heuristischen Evaluierung nachgelesen werden. Ästhetisches und minimalistisches Design Da die Erwartungen des Benutzers berücksichtigt werden, passt sich das Benutzeroberflächenkonzept dem Benutzer bestmöglich an. Des Weiteren werden dem Benutzer ausschließlich jene Möglichkeiten auf einer Seite der Webapplikation angeboten, die er brauchen kann. Der Benutzer wird nicht durch unnötige Informationen abgelenkt, wodurch er sich auf die Erledigung seiner Aufgabe konzentrieren kann. Letztlich obliegt es jedoch dem Grafikdesigner, wie die Webapplikation gestaltet sein soll. Es empfiehlt sich aber eine klare Linie beizubehalten und auf möglicherweise störende Dekoration zu verzichten, da bei dieser Webseite die Funktionalität im Vordergrund steht. Kongruenz von System und realer Welt Zum Teil wird auf der Benutzeroberfläche eine Sprache eingesetzt, die für Benutzer auch ohne das Aufgabenmodell zu kennen verständlich ist. Es kommen allerdings auch einige Begriffe zum Einsatz, die eng mit dem Aufgabenmodell verbunden sind (z. B. Leuchtkasten). Dabei sind diese Begriffe nicht neu erfunden, sondern entsprechend den Kenntnissen von fortgeschrittenen Benutzern eines Media Asset Management Systems ausgewählt. Der einzige neuartige Begriff in dem Benutzeroberflächenkonzept ist die Mediengruppe (englisch: mediagroup). Dieser Begriff wird dabei sowohl neuen als auch fortgeschrittenen Benutzern in einer Erklärung näher gebracht. Reduzierung der Gedächtnisleistung Das Benutzeroberflächenkonzept ist so ausgelegt, dass sich der Benutzer keinerlei Informationen über das System merken muss. 106

117 16. Evaluierung der Benutzeroberfläche 107 Abbildung 16.1: Kriterienkatalog für die Evaluierung des Benutzeroberflächenkonzepts. Beim Durchsuchen der Media Assets werden dem Benutzer die vorhanden Kategorien, Mediengruppen und Schlagwörter in einem Finder zum Durchstöbern angeboten. Auch bei der erweiterten Suche kann der Benutzer in einem Finder die zu durchsuchenden Kategorien und Mediengruppen einschränken. Nach dem Absetzen einer Suche wird dem Benutzer das Suchformular vorausgefüllt zum Verfeinern angeboten. Bei der Struktur- und Benutzerverwaltung werden dem Benutzer stets alle verfügbaren Elemente angezeigt. Der Bearbeitungsblock solch einer Seite enthält den Titel des ausgewählten Elements. Auch die Eingabefelder sind mit den Informationen über ein Element vorausgefüllt.