Schweitzer Fachinformationen
Wenn es um professionelles Wissen geht, ist Schweitzer Fachinformationen wegweisend. Kunden aus Recht und Beratung sowie Unternehmen, öffentliche Verwaltungen und Bibliotheken erhalten komplette Lösungen zum Beschaffen, Verwalten und Nutzen von digitalen und gedruckten Medien.
Dieses Kapitel dokumentiert eine Fallstudie zur Designentwicklung eines »What-You-See-Is-What-You-Get« (oder kurz »WYSIWYG?«)-Texteditors namens Lexi?. Sie demonstriert verschiedene Problemstellungen, die sich im Design von Lexi und ähnlich gearteten Anwendungen ergeben können, und zeigt auf, wie sie sich mithilfe von Design Patterns beheben lassen. Insgesamt werden zu diesem Zweck acht verschiedene Patterns eingesetzt und anhand konkreter, nachvollziehbarer Beispiele ausführlich erläutert.
Hinweis
Das Design von Lexi basiert auf dem von Paul Calder? entwickelten Texteditor »Doc« [CL92].
Abbildung 2.1 zeigt die Benutzeroberfläche des Texteditors Lexi. Der zentrale rechteckige Anzeigebereich des Bildschirms ist für die WYSIWYG-Darstellung des Dokuments reserviert. Hier können die gewünschten Text- und Grafikelemente beliebig zusammengestellt und mit verschiedenen Formatierungsstilen ausgestattet werden. An den Bildschirmrändern befinden sich die üblichen Pulldown-Men?üs und Scrollleis?ten sowie eine Reihe von Seitensteuerungsicons, die den gezielten Aufruf einer bestimmten Dokumentseite ermöglichen.
Im Folgenden werden sieben Problemstellungen des Lexi-Designs betrachtet:
Dokumentstruktur?. Die Wahl der internen Darstellung des Dokuments beeinflusst nahezu jeden Aspekt des Anwendungsdesigns. Sämtliche Bearbeitungs-, Formatierungs- und Anzeigeaktivitäten sowie Textanalysen erfordern eine Traversierung, also das systematische Durchlaufen aller Strukturelemente der Oberflächendarstellung - insofern wirkt sich die Art und Weise, wie diese Informationen organisiert sind, auch auf das Design der übrigen Bestandteile von Lexi aus.
Abb. 2.1: Die Benutzeroberfläch?e des Texteditors »Lexi«
Formatierung. Wie genau ordnet Lexi die Texte und Grafiken eigentlich in Zeilen und Spalten an? Welche Objekte sind für die Umsetzung der diversen Formatierungsrichtlinien zuständig? Und wie interagieren diese Richtlinien mit der internen Darstellung des Dokuments?
Ausgestaltung der Benutzeroberfläche. Die Benutzeroberfläche von Lexi umfasst Elemente wie Scrollleisten, Rahmen und Schlagschatten, die zur optischen Gestaltung der WYSIWYG-Oberfläche zur Verfügung stehen und während des Designprozesses in der Regel recht häufig variiert werden. Deshalb müssen sie so problemlos wie möglich hinzugefügt und entfernt werden können, ohne dass die übrigen Bestandteile der Anwendung davon beeinträchtigt werden.
Unterstützung mehrerer Look-and-Feel-Standards. Die Lexi-Benutzeroberfläche sollte sich möglichst leicht und ohne größere modifizierende Eingriffe an verschiedene Look-and-Feel-Standards wie Motif? oder Presentation Manager? (PM) anpassen lassen.
Unterstützung verschiedener Fenstersysteme?. Unterschiedliche Look-and-Feel-Standards werden im Allgemeinen auf verschiedenen Fenstersystemen implementiert. Das Lexi-Design sollte daher möglichst neutral und weitgehend unabhängig von einem bestimmten Fenstersystem gestaltet sein.
Userseitige Vorgänge. Die User steuern Lexi mithilfe verschiedener Elemente, die auf der Benutzeroberfläche zur Verfügung stehen, wie z. B. Schaltflächen und Pulldown-Menüs, deren Funktionalität? sich über die in der Anwendung verfügbaren Objekte verteilt. Die Herausforderung hierbei besteht in der Bereitstellung eines einheitlichen Mechanismus sowohl für den Zugriff auf diese verteilte Funktionalität als auch für das Rückgängigmachen ihrer Auswirkungen.
Rechtschreibprüfung und Silbentrennung. In welcher Form unterstützt Lexi analytische Operationen wie beispielsweise die Rechtschreibprüfung oder die Silbentrennung? Wie lässt sich die Anzahl der Klassen minimieren, die zur Ergänzung einer neuen analytischen Funktion geändert werden müssen?
Jede dieser Designfragen impliziert neben einer Reihe von Zielsetzungen auch feste Rahmenbedingungen für deren Realisierung. Deshalb werden diese beiden Faktoren im Folgenden zunächst eingehend analysiert und als Grundlage für den Entwurf eines geeigneten Lösungsvorschlags herangezogen. Anschließend werden dann die für die einzelnen Problemstellungen und deren Lösungen jeweils relevanten Design Patterns kurz vorgestellt.
Ein Dokument stellt im Prinzip nichts anderes dar, als eine spezifische Anordnung von grundlegenden grafischen Elementen wie Zeichen, Linien, Polygonen und anderen Formen. Diese Elemente spiegeln alle inhaltlichen Informationen des Dokuments wider. Autoren begreifen sie allerdings nicht als grafische Bausteine, sondern als physische Struktur des Dokuments - also als Zeilen, Spalten, Abbildungen, Tabellen und andere Substrukturen. Und diese Substrukturen besitzen wiederum eigene Substrukturen usw.
Die Verfasser eines Dokuments orientieren sich überwiegend an dessen logischer Struktur, d. h. an seiner Unterteilung in Sätze, Absätze, Abschnitte und Kapitel. Der Einfachheit halber werden in der internen Darstellung dieses Beispiels jedoch keine spezifischen Daten zur logischen Struktur gespeichert. Grundsätzlich ist die hier beschriebene Designlösung allerdings auch für die Repräsentation derartiger Informationen geeignet.
Im Fall von Lexi soll die Benutzeroberfläche den Usern die direkte Bearbeitung der Substrukturen gestatten. So sollen sie zum Beispiel in der Lage sein, ein Diagramm in seiner Gesamtheit und nicht als eine Ansammlung einzelner grafischer Primitive zu behandeln. Ebenso soll auch eine Tabelle als Ganzes referenziert werden können und nicht als eine unstrukturierte Ansammlung von Text und Grafiken - dadurch bleibt die Benutzeroberfläche überschaubar und intuitiv. Um die Lexi-Implementierung mit derartigen Eigenschaften auszustatten, wird in diesem Fallbeispiel eine interne Darstellung gewählt, die der physischen Struktur des Dokuments entspricht.
Insbesondere soll sie folgende Anforderungen erfüllen:
Die physische Struktur des Dokuments, d. h. die Anordnung von Text und Grafiken in Zeilen, Spalten, Tabellen etc., bleibt erhalten.
Das Dokument wird visuell generiert und präsentiert.
Die Mapping-Koordinaten der einzelnen Elemente in der internen Darstellung werden am Bildschirm angezeigt. Sie gestatten Lexi zu bestimmen, worauf sich der User bezieht, wenn er auf ein Bildschirmelement zeigt.
Darüber hinaus sind außerdem einige Rahmenbedingungen zu berücksichtigen. Zum einen soll ein einheitlicher Umgang sowohl mit Text als auch mit Grafiken möglich sein, damit die User Gelegenheit haben, Text beliebig in Grafiken einzubetten und umgekehrt. Grafiken sind also nicht als Spezialfall von Text und Text ist nicht als Spezialfall von Grafiken zu behandeln - denn das hätte redundante Formatierungs- und Manipulationsmechanismen zur Folge. Stattdessen soll hier lediglich ein einziger Mechanismus für Text und Grafiken genügen.
Und zum anderen soll die Implementierung in der internen Darstellung nicht zwischen einzelnen Elementen und Elementgruppen unterscheiden müssen. Vielmehr soll Lexi die einheitliche Behandlung von einfachen sowie von komplexen Elementen und somit beliebig vielschichtige Dokumente ermöglichen. So könnte beispielsweise das zehnte Element in Zeile 5 der Spalte 2 ein einzelnes Zeichen oder auch ein aufwendiges Diagramm mit vielen Unterelementen sein. Solange gewährleistet ist, dass sich dieses Element eigenständig zeichnen und seine Dimensionen selbst spezifizieren kann, hat seine Komplexität keinen Einfluss darauf, wie und wo es auf der Seite erscheinen wird.
Dieser zweiten Rahmenbedingung steht jedoch die Notwendigkeit entgegen, dass z. B. Textpassagen innerhalb des Dokuments auf Rechtschreibfehler, potenzielle Silbentrennstellen und Ähnliches hin überprüft werden müssen. Oftmals spielt es dabei keine Rolle, ob es sich bei dem untersuchten Element um ein einfaches oder ein komplexes Objekt handelt, in einigen Fällen sind derartige Analysen allerdings unmittelbar von der Beschaffenheit des Objekts abhängig. So wäre es beispielsweise nicht sinnvoll, ein Polygon auf Rechtschreibfehler oder Silbentrennstellen zu überprüfen. Deshalb sollten solche wie auch andere potenziell konfliktträchtige Rahmenbedingungen stets von vornherein im Design der internen Darstellung berücksichtigt werden.
Eine allgemein gebräuchliche Technik für die Darstellung hierarchisch strukturierter Informationen ist die rekursive Komposition, die darauf basiert, dass zunehmend...
Dateiformat: ePUBKopierschutz: ohne DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet – also für „glatten” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Ein Kopierschutz bzw. Digital Rights Management wird bei diesem E-Book nicht eingesetzt.
Weitere Informationen finden Sie in unserer E-Book Hilfe.
Dateiformat: PDFKopierschutz: ohne DRM (Digital Rights Management)
Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Ein Kopierschutz bzw. Digital Rights Management wird bei diesem E-Book nicht eingesetzt.