5. Umsetzung der theoretischen Erkenntnisse in praktische WBTs

In diesem Kapitel steht die Vorstellung der im Rahmen dieser Diplomarbeit entwickelten WBTs an. Nach einer kurzen Beschreibung der jeweiligen Anwendung, werden die wesentlichen und wichtigen Techniken erklärt und dokumentiert. Auf eine ausführliche Dokumentation jedes einzelnen Programmpunktes wurde aus Platzgründen verzichtet. Es wurde im besonders Wert darauf gelegt, die Neuerungen im Vergleich zu bisherigen WBTs zu erläutern, um dem Interessierten die Implementierung der Konzepte in eigenen Projekten zu erleichtern.

In diesem Zusammenhang erfolgt auch eine Besprechung der Probleme, welche bei der Entwicklung aufkamen. Letztlich werden dem Leser Anregungen gegeben, wie die vorgestellten Techniken durch zusätzliche Module und Verbesserungen an Effektivität und Nutzen gewinnen könnten.

5.1 Der Weg zur besseren Homepage - Umsetzung eines Tutorials

5.1.1 Kurzübersicht

Mit Der Weg zur besseren Homepage wurde ein passives Tutorial zum Thema Webpage-Design entwickelt. Wegen der Einfachheit der Sprache HTML ist es auch weniger versierten Computerbenutzern leicht möglich eine eigene Homepage zu kreieren. Leider muß festgestellt werden, daß dies auch vermehrt Probleme mit sich bringt. Ergebnis vieler Bemühungen mit fehlendem Wissen um das Design sind Homepages die:

Das Ziel des Kurses liegt deshalb in der Vermittlung dieses Wissens. Inhaltlich kommen die Bereiche technische Realisierung, Informationsorganisation, graphische Aufbereitung und Layout zu Ansprache. Die in kleine Einheiten unterteilten Themenkomplexe sind durch Beispiele und interaktive Anwendungen veranschaulicht. Das Angebot selbst steht im WWW zur direkten Bearbeitung oder zum Download bereit. Für die Benutzung wird eine Browsersoftware mit JavaScript Version 1.1 Unterstützung voraus gesetzt.

Erklärtes Ziel des WBT Projektes war es, ein Tutorial unter festgelegten Voraussetzungen mit bestimmten definierten Funktionen auf Hypertextbasis zu entwickeln. Als technische Forderungen galten:


Als geforderte Funktionen wurden definiert:

5.1.2 Dokumentation

Entwicklung des Kursinhalts

Der Kursinhalt wurde unabhängig vom Darstellungsmedium gesondert aufbereitet. Als Vorlagen dienten diverse Style Guides verschiedener Autoren. Deren Ausführungen und Ratschläge wurden einander ergänzend zu einem Themenkomplex zusammengefaßt und in 4 große Bereiche unterteilt. Jeder Bereich für sich wurde nochmals in einzelne insich abgeschlossene Einheiten unterteilt. Dies ermöglicht es kleine Lernabschnitt aufzubauen und damit den Forderungen nach Modularisierung gerecht zu werden.

Der Lerner kann so durch "Mikrolernen" das Thema selbständig entdecken. Es gibt nicht mehr den Einstiegspunkt A mit der Abfolge bis Z, sondern das Wissen ist in einem Pool mit vielen kleinen Einzelteilen angeordnet.

Basierend auf dem Kursinhalt wurden für die Wissensabfrage eine Palette an Fragen mit entsprechenden Antworten formuliert. Außerdem wurde eine Liste mit eventuell nicht bekannten Begriffen heraus gefiltert, welche als Grundlage für ein Glossar dienen. Um den inhaltlichen Bereich auch einem mehr visuellen Lerner gerecht zu werden, wurde wo möglich und sinnvoll das Thema durch eine Grafik veranschaulicht.

Strukturierung des Kursinhalts

Die modulare Aufteilung des Themas spiegelt sich auch in dem grundsätzlichen Gerüst der Datenstrukturierung wieder. Traditionell wird eine auf HTML-basierende Seite für die Darstellung in einem Webbrowser seitenweise strukturiert. Die Gestalt ähnelt dabei sehr stark der einer Seite in einem Buch. Dies hat zwei entscheidende Nachteile:

  1. Immer nur ein Informationskomplex ist für den Benutzer sichtbar. Die Einordnung des Themas in der Gesamtheit ist erschwert. Das Einschieben von Zusatzinformtionen wie einem Glossar führt zu zusätzlicher Verwirrung.
  2. Um die Verwaltung der Dokumente rationell zu gestalten, müssen größere Datenmengen auf einer Seite untergebracht werden. Längere Übertragungszeiten sind die Folge, wobei Informationen mit Übertragen werden, die für den Benutzer vielleicht gar nicht von Interesse sind.

Um diese Nachteile zu umschiffen, wurde ein alternativer Ansatz mit Hilfe der Frametechnologie gestartet. Durch den Einsatz von Frames ist es möglich, ein Browserfenster in definierte Bereiche (sogenannte Frames) aufzuteilen. Jeder dieser Frames hat die Fähigkeit zur Darstellung eines HTML-Dokumentes. Alle Eigenschaften des Browserfensters wie scrollen bei Überlänge etc. werden von den Frames geerbt. Auf diesem Grundsatz basierend ist der Entwickler in der Lage:

  1. Die Informationstiefe der Daten übersichtlich zu erweitern, ohne das der Lerner den Überblick verliert.
  2. Zusätzlich Informationen, wie zum Beispiel ein Glossar einzuschieben, ohne den eigentlichen Text aus dem Sichtfeld des Lerners zu entfernen.
  3. die Übertragungszeiten zu verkürzen, da immer nur die gerade gewünschten Informationen angezeigt bzw. nachgeladen werden.

Hinzu kommt, daß diese Darstellungsweise dem Modularen Aufbau des Kurses sehr entgegenkommt. Abbildung 26 und 27 erläutern die strukturellen Unterschiede der beiden Methoden im Hinblick auf die Navigation durch das Informationsangebot.

  • Dokumentenorganisation seitenorientiert
  • Abbildung 26

    ©1997,T.Hofmann







    Vom Zentraldokument ausgehend, wird über einen Index zu thematisch organisierten Dokumenten navigiert. Die Navigation innerhalb eines Themenbereiches erfolgt dann linear von Dokument zu Dokument. Zusatzinformationen wie ein Glossar werden durch Verzweigungen zu einem eingeschobenen Dokument dargeboten.

    Die Pfeile zeigen die Navigationsrichtung an.

  • Dokumentenorganisation in Frames
  • Abbildung 27

    ©1997,T.Hofmann





    Alle gezeigten Dokumente sind gleichzeitig am Bildschirm darstellbar. Erreicht wird dies durch die Frametechnologie. Von einem Navigationsframe mit Menüleiste aus wird ein Hauptdokument zu einem Thema in einen Frame geladen. Zusazinformationen werden in Frames auf der gleichen Bildschirmseite bei Bedarf angezeigt, ohne daß das Hauptdokument entfernt werden muß. Die Navigationsrichtung geht in die Tiefe, d.h. die "Auflösung" der Informationen nimmt zu.

    Die linke Grafik veranschaulicht die serielle Navigation durch die Dokumente . Ausgehend von einem Inhaltsverzeichnis (Zentraldokument) führt die Navigation über einzelne Seiten schließlich wieder zurück. Erkennbar ist auch die eingeschobene Seite mit zusätzlichen Informationen. Im Gegensatz dazu zeigt das Bild unten einen Frameorientierten Ansatz. Ausgehend von dem Inhaltsverzeichnis werden Dokumente in einen zweiten Frame geladen. Von diesem Frame aus werden wieder Dokumente in weiteren Frames dargestellt. Die Navigation ist nicht mehr seriell gerichtet, sie ist hierarchisch organisiert.

    In den Abbildungen 28 und 29 sind zu jeder Struktur entsprechende Bildschirmdarstellungen aus praktischen Beispielen zu sehen.

  • Beispiel für Seitenorientierung
  • Abbildung 28

    Quelle: http://www.fhd-stuttgart.de/asta/













    Seitenorientierte Darstellung

    am Beispiel des WWW-Style-Guides

    der Hochschule Stuttgart

    Das Thema ist auf einer Seite erläutert. Navigationsbutton am unteren Bildschirmrand verdeutlichen die Lineare Navigation. Neben vor- und zurückblättern (durch Pfeile signalisiert) ist die Navigation zurück zur Inhaltsübersicht möglich.

  • Beispiel für Framedarstellung
  • Abbildung 29

    ©1997,T.Hofmann






    Darstellung in Frames

    im Tutorial

    Der Weg zur besseren Homepage

    Im Kopfbereich des Fensters ist eine Navigationsleiste mit Verweisen auf verschiedene Themenbereiche angezeigt. Links darunter zeigt ein Informationsframe das gerade aktive Thema und Unterthema an. Das Hauptdokument des Themas ist darunterliegend zu sehen. Rechts ist ein Bereich mit Optionen für vertiefende Informationen. Nicht themenspezifische Informationen werden im Frame rechts unten angezeigt. In diesem Fall handelt es sich um eine Begriffserklärung des Glossars.

    Screendesign und Layout

    Der in Abbildung 29 darstellte Bildschirmaufbau bedarf genauer Erklärung. Zunächst einige Gedanken zum generellen Aufbau des Bildschirmes.

    Die Abbildung 30 kennzeichnet die verschiedenen Bereiche des Fensters. Die einzelnen Frames sind durch eine grüne Linien gekennzeichnet. Mit Nummern versehene rote Pfeile weisen auf die verschiedenen Inhalte der Bereiche hin.

    Wie in der Vergrößerung von Bild 29 zu sehen ist, besitzt das Bowserfenster nicht die bekannten Schaltknöpfe und Pulldownmenüs. Für eine einfachere Gestaltung und einen größeren Fensterbereich wurde auf diese Funktionselemente verzichtet. Alle notwendigen Navigationselemente sind dabei in der Navigationsgrafik am oberen Bildschirmrand (Bereich #1) implementiert. Lediglich die Statuszeile des Fensters am unteren Rand wurde für die Ausgabe von zusätzlichen Informationen zu Hyperlinks beibehalten.

  • Struktureller Bildschirmaufbau
  • Abbildung 30










    4

    ©1997,T.Hofmann



    1

    2

    3

    4

    5

    6

    7

    Die inhaltliche Zuordnung der Nummern und Namen der Frames ist aus der Tabelle unten zu entnehmen. Die Namen der Frames beziehen sich auf die Namensgebung im Frameset, und ist für die eindeutige Referenzierung in Target-Tags notwendig. Die unter #4 benannten Platzhalter sind aus gestalterischen Gesichtspunkten eingefügt.

    Legende zu Abbildung 30 Tabelle 3

    ©1996,T.Hofmann









    Die Tabelle stellt Verbindung zwischen den unter Abbildung 30 eingeführten Nummern und den für die Referenzierung in JavaScript und HTML verwendenten Namen der Frames her. Ferner wird eine Beschreibung der Funktion jedes Frames gegeben.

    Durch die große Anzahl an Frames kann die Referenzierung recht undurchsichtig werden. Es wurde deshalb eine Baumstruktur, wie in Abbildung 31 dargestellt, gebildet. Die Struktur zeigt neben den Dateinamen auch die Namen der referenzierbaren Frames. Die hierarchische Struktur des Baumes ist mit dem Ladevorgang für die einzelnen Dateien und den in Ihnen definierten Framesets gleichzusetzen. Im Klartext heißt dies, daß nach einer Fehlerprüfung in der Datei check.htm die Dateien frset1.htm bis frset7.htm respektive der eingebetteten Framedokumente geladen werden. Wichtig ist zu wissen, daß für die eindeutige Referenzierung jeder Frame eindeutig definiert und damit ansprechbar ist. Für die erstmalige Initialisierung wurde die Datei leer.htm verwendet.

  • Baumstruktur der Framesets
  • Abbildung 31

    ©1997,T.Hofmann




    Die Baumstruktur beschreibt die Reihenfolge der Initialisierung der einzelnen Frames. Bei den Oval umrandeten Bezeichnungen handelt es sich um die Namensdefinitionen der tatsächlich vorhandenen Frames. Da der Inhalt variabel ist, wurden keine Dateinamen angegeben. Angesprochen wird ein Frame mit der Top-down-Methode unter Beachtung aller Framesets. Die Platzhalterframes werden mit der Dateien leer.htm initialisiert und benötigen keinen Namen zur Refernzierung.

    Nach dem die Initialisierung nach diesem Grundgerüst vollendet ist, lassen sich die einzelnen Bereiche direkt ansprechen. Um beispielsweise durch einen Verweis im Frame opti2 ein Dokument in den Frame main zu laden, würde eine Referenz im Stile von top.frset2.frset3.frset5.main im Target-Tag ausreichen. top bezieht sich dabei auf den äußersten Framecontainer in der Datei frset1htm. Über die Knoten erfolgt dann der Verweis auf main. Zwar können die Referenzierungen unter Umständen sehr lang werden, jedoch ist nur durch diese Vorgehensweise eine nachvollziehbare Strukturierung möglich.

    Dateiorganisation

    Nach dem vollständigen Laden aller Dateien und der Initialisierung aller Frames, gestaltet sich der Aufruf einzelner Dateien nach dem in Abbildung 27 gezeigten Informationsfluß. Durch wählen eines Themas in der Navigationsleiste, wird eine Datei (index.htm) in den Frame pfad geladen, die wiederum Informationen über das zu ladende Dokument für den Frame main und opti1 enthält. In main wird hier eine Übersicht der Unterthemen geladen, der Frame opti1 hingegen bleibt leer. Wählt der Lerner nun ein Kapitel aus der Übersicht auf, wird eine neue Datei in den Frame pfad geladen, die wiederum Informationen über Dateien für main und opti1 verfügt. Main zeigt jetzt den Lehrtext und opti1 die damit verbundenen Optionen für Darstellung unterstützender Beispiele und Grafiken. Die Informationen über den Ablageort dieser Dateien beinhaltet jetzt das Dokument in opti1, welche diese auf Wunsch des Lerner in den Frame opti2 lädt.

    Die in den Lehrtexten vorhandenen Verweise zu Begriffserklärungen zielen auf den Frame glossar und laden das entsprechende Dokument in diesen Bereich.

    Das beschriebene Schema spiegelt sich auch in der Organisation der Dateien und Verzeichnisse auf dem WebServer wieder. Die Verzeichnisstruktur in Abbildung 32 dient zur Veranschaulichung. Jedes Thema ist in einem eigenen Unterverzeichnis abgelegt, welches wiederum über Unterverzeichnisse zu den Kapiteln verfügt. Den Optionen Glossar, Medien, Info und Wissensabfrage in der Navigationsgrafik sind ebenfalls eigene Unterverzeichnisse zugeordnet.

  • Verzeichnisstruktur des Tutorials
  • Abbildung 32

    ©1997,T.Hofmann



















    Die Übersicht zeigt die Struktur der Veizeichnisse des Tutoriums, wie sie auf dem Webserver bzw. der lokalen Festplatte zu finden sind.

    Beschleunigung der Darstellung von Informationen

    Die Forderung nach sinnvoller Ausnutzung kann auch gleichgestellt werden mit der Forderung nach kurzen Ladezeiten. Um den Eindruck eines schnelleren Informationsflusses beim Laden von Informationen zu erwecken, wurden einige Maßnahmen getroffen:

    Wird die zuvor beschriebene Baumstruktur der Frames noch einmal hergenommen, dann ist ersichtlich, daß die Platzierung von Funktionen bzw. das Pre-loading von Elementen sehr weit oben in der Hierarchie erfolgen muß, um eine Verfügbarkeit für weiter unten liegende Frames zu gewährleisten.

    Implementiert wurden diese Eigenschaften einmal in der Datei frset2.htm und in der Datei loader.htm. Die Datei loader.htm lädt durch ein JavaScript diverse Grafikdateien in einen Variablenspeicher. Zudem sind im Dokument Sounddateien eingebettet, die sich später über eine Referenz ansprechen lassen und automatisch mit Aufruf des Dokumentes geladen werden. In der frset2.htm Datei hingegen sind lediglich Scriptfunktionen für Popupfenster abgelegt. Der Aufruf erfolgt über die Referenz top.frset2.startit() . Dem Funktionsaufruf können Optionen über das Erscheinungsbild und den Inhalt des neuen Fensters mitgegeben werden.

    Die Modulariserung der Informationen wurde bereits bei der Aufbereitung des Kursinhalts vorgenommen und in der Framestruktur fortgesetzt. So werden beispielsweise erst nacheinander Kapitelübersicht, Lehrtext und Beispiele geladen, ohne wichtige Elemente wie die Navigationsleiste oder vielleicht den Lehrtext aus dem Sichtfeld zu entfernen. Dies spiegelt den entscheidenden Unterschied zu herkömmlichen Ansätzen wider. Außerdem sind die Begriffe des Glossars in ca. 60 einzelnen Dateien untergebracht, mit einer Größe von je 1kbyte. Da immer nur ein Begriff gesucht wird ist das Laden einer Gesamtliste nicht sinnvoll und verlangsamt nur den Informationsfluß.

    Glossar

    Die Liste der aus dem Lehrtext gefilterten Begriffe, die möglicherweise dem Lerner unbekannt sein könnten, jedoch für das Verständnis wichtig sind wurde in einzelne Dateien unterteilt. Je Begriff existiert eine Datei. Nachdem bereits beschriebenen Schema des Informationsflußes werden die Dokumente mit dem Begriff in den Glossar-Frame geladen. Um dem Lerner auch eine Übersicht zu allen erklärten Wörtern zu geben, wurde eine alphabetisch geordnete Liste angelegt, die über die Naviagtionsleiste aufgerufen wird. Im Frame pfad erhält der Benutzer zusätzlich eine Buchstabenliste mit Verweisen, um die Navigation zusätzlich zu erleichtern.

    Wissenskontrolle

    Bisher implementierte Wissenkontrollen für das WWW basieren auf CGI-Scripten. Eine Analyse dieser Systeme ist in [Gibson] besprochen. Ein praktischen Beispiel ist unter http://rw20hr.jura.uni-sb.de/cc1/tutorien/tutframe.htm implementiert. Wesentlicher Nachteil dieser Serverside-Methode ist jedoch die fehlende Möglichkeit der Offline-Bearbeitung, da die Auswertung der Fragen eben auf dem Webserver stattfindet. Mit Java und JavaScript ist es aber jetzt möglich, Aktionen dieser Art auf Clientseite zu übertragen. Neben der Offline-Bearbeitung zeigen sich auch in der Auswertungsgeschwindigkeit Vorzüge.

  • Bildschirmdarstellung der Wissenskontrolle
  • Abbildung 33

    ©1997,T.Hofmann

     






    Die Abbildung zeigt einen Screenshot der Wissenskontrolle nach dem starten des Zählers (5).

    Der Test wird durch Drücken des Schaltknopfes Test beginnen (2) gestartet. Mit den Knöpfen Test abbrechen (3) und Test auswerten (4) wird der Zähler gestoppt bzw. die Anworten ausgewertet.

    Im Tutorial wurde die Wissenskontrolle durch 25 vordefinierte Fragen verwirklicht, welche im Multiple-choice-Verfahren (vergleiche Abbildung 33) beantwortet werden müssen. Für die Beantwortung der Fragen ist eine bestimmte Zeit vorgegeben. Die verbleibende Zeit wird dem Benutzer dabei durch einen Zähler angezeigt. Die Zählung beginnt, sobald der Ladevorgang des Dokumentes mit den Fragen beendet ist. Ist der Benutzer vor Ablauf der Zeit mit der Beantwortung der Fragen fertig, kann er die Auswertung selbst starten, sonst wird sie automatisch nach Abblauf der Zeit gestartet. Nach der Auswertung wird dem Lerner eine Liste mit Verweisen zu Themen präsentiert, die als Wissenslücken durch falsche Beantwortung der entsprechenden Frage identifiziert wurde. Die Verweise werden dabei geordnet und mit Bezeichnung des Themas in einem separaten Fenster angezeigt.

  • Bildschirmdarstellung der Ergebnisauswertung der Wissenskontrolle
  • Abbildung 34

    ©1997,T.Hofmann

     





    Die Abbildung zeigt einen Screenshot des Auswertungsfensters der Wissenskontrolle.

    Dem Benutzer wird in einer kleinen Statistik die Anzahl der richtigen Antworten und der prozentuale Anteil an allen Fragen angezeigt (1). In einer Liste werden neben Verweisen (3) zu den Themengebieten auch die zugehörigen Hauptthemen (2) angezeigt. Drücken des Schalters Fenster schließen (4) schließt die Liste.

    Im Rahmen dieser Arbeit war es nicht das Ziel, ein ausgereiftes System unter allen Gesichtspunkten, wie sie in [Gibson] beschrieben werden, zu verwirklichen. Vielmehr wurde eine generelle funktionale Abfrage auf ClientSeite implementiert. Im folgenden eine Abbildung zum funktionalen Aufbau des Wissensabfragemoduls.

  • Funktionsstruktur der Wissenskontrolle
  • Abbildung 35

    ©1997,T.Hofmann















    Die Wissenabfrage wird durch den Benutzer gestartet. Alle Fragen werden in einem Dokument vereint auf einmal geladen. Eine rückwärtslaufende Uhr signalisiert dem Benutzer die verbleibende Zeit. Die Auswertung wird entweder nachAblauf der Zeit oder durch Benutzeraktion gestartet.

    In einem Ausgabefenster werden Links zu Themen aufgezeigt, die der Benutzer in der Abfrage falsch beantwortet hat.

    Durch klicken wird das entsprechende Dokument zum Thema in den Frame "main" geladen. Der Benutzer kann jederzeit in die Liste zurück und ein anderes Thema in Augenschein nehmen. Nach dem Schließen des Ausgabefensters werden die Ergebnisse, d.h. die Liste der Links verworfen.

    Interaktive Beispielanwendungen

    Um einige Themen lebhafter zu gestalten, werden sie durch Interaktive Beispiele unterstützt. Im einzelnen sind dies ein Beispiel für:

  • Bildschirmdarstellung der Übertragunsdauerberechnung
  • Abbildung 36

    ©1997,T.Hofmann

     




    Die Abbildung zeigt einen Screenshot der Anwendung zur Berechnung der Übertragungsdauer.

    Im vorliegenden Beispiel wurde aus der Pulldown-Liste als Provider Compuserve (1), bei analoger Verbindung (2) mit einer Datenmenge von 43kb (4) gewählt.

    Als Übertragungszeit wurden mit einem Datendurchsatz von 1.37kb/sek. (3) 26 Sekunden (6) berechnet. Die Berechnung wird durch Drücken des Berechnen-Knopfes (5) ausgelöst. Geschlossen wird die Anwendung über den Fenster schließen-Knopf (7).

    Die angegebenen Werte für den Datendurchsatz wurden von der Zeitschrifft c't in einem Test ermittelt. Weitere Einzelheiten sind unter [Wilde] nachzulesen.

  • Bildschirmdarstellung der Anwendung zur Sonderzeichenumwandlung
  • Abbildung 37

    ©1997,T.Hofmann

     







    Die Abbildung zeigt einen Screenshot der Anwendung zur Umwandlung von Sonderzeichen und Umlauten in HTML maskierte Zeichen.

    Im grün umrandeten Kasten (1) befinden sich der Aktionsbereich der Anwendung. In den Linken Felder können ISO-Zeichen (2) bzw. HMTL maskierte Zeichen (3) eingegeben werden. Durch Drücken der entsprechenden Knöpfe (4) wird die Umwandlung gestartet. Das Ergebnis wird in den Feldern (5) und (6) ausgegeben.

    Drücken des Fenster schließen-Knopfes (7) beendet die Anwendung.

  • Bildschirmdarstellung der FarbenPicker-Anwendung
  • Abbildung 38

    ©1997,T.Hofmann

     







    Die Abbildung zeigt einen Screenshot der FarbenPicker-Anwendung.

    Der Benutzer kann die Farbeigenschaften von Hintergrund (1), Text (2), Link (3) und besuchtem Link (4) beeinflussen.

    Die Farbe wird über die Farbpalette (5) gewählt. Der Farbcode der aktuellen Farbe wird in der Statuszeile (6) angezeigt. Im Ausgabebereich (7) werden die verschiedenen Einstellung mit den zugehörigen Farbcodes automatisch dargestellt.

    Der Fenster schließen-Knopf (8) ermöglicht es die Anwendung zu beenden.

    Auf eine genauere Erläuterung der Beispiele bzw. der Programmcodes muß im Rahmen dieser Arbeit verzichtet werden. Die Beispiele können über den Optionspunkt medien und die darunter erscheinende Liste mit verfügbaren Medien direkt aufgerufen werden. Der Sourcecode zu den jeweiligen Anwendungen ist im Anhang auszugsweise abgedruckt.

    5.1.3 Implementierungsprobleme

    Browsersoftwarekompatibilität

    Für die Realisierung aller geforderten Funktionen war es notwendig auf den erweiterten JavaScipt-Befehlssatz der Version 1.1 zurück zu greifen. Vor allem im Bereich der Unterstützung multimedialer Formate wie Audiodateien, aber auch für einige systemspezifische Funktionen wie das Bestimmen von installierten Plugins. Leider wird JavaScript1.1 derzeit nur von Netscapes Navigator ab Version 3.0 unterstützt. Der Einsatz von Microsofts Explorer oder NCSAs Mosaic scheidet vorerst aus, bis kompatible Versionen verfügbar sind. Damit schränkt sich die Anzahl der potentiellen Benutzer ein.

    Referenzierung zwischen Frames

    Wurde anfänglich die Definierung der Frames in einer einzigen Datei durchgeführt, was vor allem die Ladezeiten erheblich beschleunigt, so stellt sich die Referenzierung als äußerst schwierig heraus. Aus diesem Grund wurde die unter 5.1.2 beschriebene Struktur für die Initialiserung der Frames gewählt. Zwar ist damit eine Referenzierung untereinander einfach möglich, bei geringen Bandbreiten des Internetzugangs kann es jedoch beim Laden der einzelnen Frameset zu Problemen kommen. Das Resultat sind nicht initialisierte Frames. Im Extremfall muß dann das Browserfenster geschlossen und die Seite neu aufgerufen werden.

    In Tests ist dieses Problem nur gelegentlich bei sehr langsamen Verbindungen aufgetreten. Für einen unerfahrenen Benutzer führt diese jedoch zu unnötiger Verwirrung. Abhilfe könnte auf zweierlei Weise erzielt werden:

    1. Zusammenfassung aller Frameset-Dateien in einer einzigen Datei mit Registrierung der Frames in einer Variablentabelle mittels JavaScript. Durch geeignete Verwaltung könnten Referenzierungen dann einfach vorgenommen werden. In [Danesh] wird das Idaho Frameset von Bill Dortch vorgestellt, das genau diesen Zweck erfüllt.
    2. JavaScipt1.1 sieht Befehle für die Fehlerbehandlung vor. Durch eine Funktion an entsprechender Stelle könnten Fehler abgefangen werden, die durch zeitbedingte Ladeprobleme hervorgerufen werden.

    Auf die Implementierung einer der beiden Lösungen wurde verzichtet, da die Problematik als nicht so wesentlich angesehen wird, als daß sie entscheidend zum Tragen kommt. Es sollte nur auf diesen Sachverhalt aufmerksam gemacht werden, um auf etwaige Probleme in Verbindung mit der Implementierung eines komplexen Frameskonzeptes hinzuweisen.

    Reload durch Resize des Browserfensters

    Um eingebettet Scripte automatisch nach dem Laden eines Dokumentes zu starten gibt es zwei Wege. Der erste führt über einen Funktionsaufruf im BODY-Tag durch die onLoad()-Option. Die zweite Lösung kann durch das Einbinden von JavaScript-Befehlen ohne die Verwendung einer Funktion als Container erreicht werden.

    Als Problem hat sich erwiesen, daß bei einem Resize, also dem ändern der Fenstergröße ein Dokumenten Reload aus dem Speicher der Browsersoftware stattfindet. Bei diesem Reload kommt es zu dem unangenehmen Effekt, daß auch die Scripte nochmals gestartet werden. Problematisch zeigt sich dies vor allem bei Scripten, die das Vorhandensein bestimmter Elemente oder eines Dokumentes in einem Frame voraus setzen. Abhilfe kann durch Bereitstellung einer Fehlerbehandlung erreicht werden.

    Im Falle des Tutorial sollte eine Ladezustandsanzeige für Grafiken, Sounds und Dokumente realisiert werden. Es war vorgesehen, durch ein automatisch gestartetes JavaScript eine Anzeige über den Fortschritt in Prozent auszugeben, aus beschriebenen Grund jedoch nicht implementiert. Für diesen Fall würde auch eine Fehlerbehandlungsroutine nichts helfen, da ein entsprechender EventHandler für die Verfolgung des Ladestatus eines Dokumentes nicht implementiert ist. Damit kann nicht zwischen einem Reload auf Grund eines Fensterresize oder eines tatsächlichen Reloads unterschieden werden.

    5.1.4 Anregungen für Verbesserungen

    Während der Entwicklung zeigte sich, daß in bestimmten Bereichen weitere Funktionen bzw. die Vertiefung bereits bestehender Funktionen sinnvoll sind. Die hierzu aufgelisteten Gedanken, sollen als Einstiegspunkt für weitere Entwicklungen dienen.

    Benutzermodellierung

    Unter 3.1 wurde bereits die in [Ballerstraller] beschriebene Methode zur Bestimmung des Lerntyps kurz angesprochen. Die Methode ist in ihrer Struktur bestens geeignet, um in einem Algorithmus einer Lernsoftware implementiert zu werden. Auch die verwendeten Medien zur Typenbestimmung, sind für einen Test einfach bereitzustellen. Eine entsprechende Implementierung der Ergebnisse würde voraussetzen, daß die Lehrinformationen mindestens in 3 verschiedenen Ausprägungen dem Benutzer angeboten werden können. Entsprechend muß auch der Kursinhalt umfangreicher aufbereitet werden.

    Zusätzlich zur Lerntypenbestimmung, wäre die Verfolgung des Benutzerverhaltens für eine einfache Benutzermodellierung zu bewerkstelligen. Die gewonnen Daten könnten in Cookiefiles gespeichert und bei Bedarf ausgewertet werden. Aus den statistischen Auswertungen lassen sich Rückschlüsse auf den Lerntyp, Navigationsverhalten und Lernstrategien ziehen. Damit wiederum wäre es möglich den Lernstoff individuell für den Benutzer aufzubereiten.

    Eine individuelle Anpassung der Lerninhalte auf Grund der Benutzerdaten ist mit dem HTML-basierten Ansatz nur dann möglich, wenn auf Serverseite die Informationen in einer Datenbank verwaltete und "on-the-fly" aufbereitet an den Benutzer geschickt werden.

    Die Sammlung von Benutzerdaten ist leider auch eine datenrechtlich problematische Angelegenheit und sollte für den Anwender, wenn doch implementiert, zumindest transparent sein.

  • Serververwaltung von Kursinformationen
  • Abbildung 39

    ©1997,T.Hofmann









    Das Schema zeigt in welcher Weise Kursinformationen von einem WWW-Server in einer Datenbank bereit gestellt werden könnten. Die Daten werden abhängig von den Benutzerpräferenzen entsprechend aufbereitet. Da alle Benutzerdaten auf Client-Seite ausgewertet und gespeichert sind, ist der Datenschutz gewährleistet. Vom Server wird lediglich eine aufbereitete Informationsstruktur angefordert. Im Mittelpunkt steht die Interkation zwischen System und Benutzer. Der WWW-Server dient nur als dynamischer Datenspeicher.

    Wissenskontrolle

    Zwar ist die implementierte Wissenskontrolle in einigen Punkten effektiver als Anwendungen auf CGI-Basis, jedoch sind noch weitere Funktionen für einen vollwertigen Ersatz notwendig:

    Zusammenfassend ergibt sich eine Funktionsablauf, der in Abbildung 40 zu sehen ist.

  • Funktionsablauf für eine erweiterte Wissenskontrolle
  • Abbildung 40

    ©1997,T.Hofmann














    Im dargestellten Funktionsablauf stehen dem Benutzer zwei grundlegende Funktionen zu Verfügung. Zum einen die Ansicht gespeicherter Ergebnisse vorangegangener Wissenkontrollen und zum anderen die Beantwortung neuer Fragen.

    Wird eine neue Wissenkontrolle begonnen, so wählt das System nur Fragen, die noch nicht gestellt oder richtig beantwortet wurden.

    Wichtig ist anzumerken, daß die Auswertung der Antworten nicht sofort stattfindet, vielmehr erst nachdem der Benutzer alle Fragen beantwortet hat. Der Benutzer ist dann nicht geneigt, sich die Lösung einfach zeigen zu lassen. Das Lernen aus den Fehlern erfolgt mit der Präsentation der Ergebnisauswertung und den dort aufgeführten Bemerkungen und Links zu entsprechenden Themen.

    Bildschirmgestaltung

    Dem Screendesign fehlen einige wichtige Eigenschaften, wie sie zum Beispiel bei Autorensystemen zu finden sind. Im einzelnen sind aufgefallen:

  • Beispiel für einen Bubbletext
  • Abbildung 41

    ©1997,T.Hofmann






    Das Beispiel einen Screenshot aus MS-WORD95 im Betriebssystem Windows95. Der schwarze Mauszeiger steht über dem Symbol für den Befehl "Ausschneiden" in der Symbolleiste. In einem Kästchen erscheint ein Hilfetext zu dieser Funktion.

    Standardisierung des Kursgerüstes

    Die Entwicklung eines Gerüstes für Lernsoftware auf Basis von HTML mit eingelagerten erweiternden Elementen gestaltet sich für viele Anwendungsbereich ähnlich. Es bietet sich daher an das bereits bestehende Kursgerüst so aufzubereiten, daß es durch einen Wizard entsprechend für neue Kursinhalte vorbereitet werden kann.

    In Verbindung mit MS-FrontPage wäre ein solcher Wizard in der Lage komplexe Anwendungen zu realisieren. Ein entsprechender Wizard müßte mindestens über die folgenden Funktionen verfügen:

    Sonstige Anregungen

    Der Charakter des Internets ist auch durch die bidirektionale Kommunikation zwischen Anbieter und Benutzers gekennzeichnet. Die Erfahrungen des Lerners mit der Software sind von nicht zu unterschätzendem Wert. Durch die Implementierung eines Feedbackformulars mit vordefinierten Antworten könnte der Lerner dazu animiert werden dem Entwickler wichtige Informationen zu geben. Interessant sind hier zum einen Fragen über die technischen Voraussetzungen des Benutzers, wie Geschwindigkeit des Internetzuganges, verwendete Software etc.. Zum anderen sind die Eindrücke des Anwenders im Hinblick auf Gestaltung und Inhalt des Kurses von Wichtigkeit.

    Die Dauer des Ladevorganges der zu Beginn des Kurses geladenen Grafiken und Sounds kann bei einer langsamen Verbindung zum Internet bei der Onlinebearbeitung deutlich spürbar werden. Hier wäre eine Anzeige über den Status des Ladevorganges für den Benutzer informativ. Wegen der unter 5.1.3 beschriebenen Probleme beim Resize eines Fensters wurde eine bereits realisierte Zustandsanzeige wieder verworfen. Ein Medientracker, wie er für Java vorgesehen ist, könnte hier in Verbindung mit LiveConnect weiterhelfen. Wegen Zeitmangel wurde dieser mögliche Lösungsweg jedoch nicht weiterverfolgt.

    Um die Verwaltung der implementierten JavaScript-Funktionen übersichtlicher zu gestalten, wäre es hilfreich diese in einer Datei unterzubringen. Sinnvollerweise sollten dann alle Funktionen modular aufgebaut und durch Parameterübergaben vielfälltig verwendbar sein. Auch dies wurde aus Zeitgründen nicht realisiert.

    5.2 Die Anatomie-Experience - Umsetzung eines Drill and Practice

    5.2.1 Kurzübersicht

    Die Anatomie-Experience ist eine medizinische Übungssoftware für das WWW. Auf Basis der Technologien LiveConnect, Java, JavaScript, HTML und VRML (respektive Live3d) wurde unter Ausnutzung der Vorzüge der jeweiligen Techniken ein interaktives Abfragesystem für die menschliche Anatomie anhand eines Modells verwirklicht. Der momentane Entwicklungsstand umfaßt einzig das Knochenmodell des rechten Fußes. Bei der Arbeit am System wird der Lerner aufgefordert, einen Knochen in einer 3d-Szene zu finden und durch Anklicken zu benennen. Die Reihenfolge, in der die Knochen abgefragt werden, ist dabei zufällig gewählt. Bei falscher Auswahl erhält der Benutzer ein entsprechendes Feedback bzw. nach Beantwortung aller Fragen eine sortierte Liste mit den Knochennamen und der Anzahl an Versuchen um dies in der Szene zu bestimmen. Der Lerner kann für die Benutzerdialoge zwischen englischer und deutscher Sprache wählen.

    Das Angebot selbst steht im WWW zur direkten Bearbeitung oder zum Download bereit. Für die einwandfreie Funktion wird eine Browsersoftware mit Java, JavaScript- (Version 1.1), LiveConnect-Unterstützung und Live3d-Plugin vorausgesetzt.

    5.2.2 Dokumentation

    Screendesign

    Die Anatomie-Experience ist auf HTML-Basis in einem Browserfenster mit zwei Framebereichen aufgebaut. In die HTML-Dokumente sind eine VRML-Szene und JavaApplets eingebettet. Die Applets dienen zum einen zur Überwachung der VRML-Szene und zum anderen um dem Benutzer Textbausteine mit Anweisungen anzuzeigen. Zusätzliche Informationen wie eine Hilfe werden in einem separaten Fenster dargestellt. Die Programmfunktion werden über eine ClientSide-Imagemap aktiviert. Die Abbildung 42 zeigt alle wesentlichen Elemente der Bildschirmdarstellung. In Abbildung 43 ist eine Serie von Screenshots mit Ausschnitten der VRML-Szene aufgereiht. Dargestellt wird die Rotation des Fußknochens.

  • Bildschirmlayout der Anatomie-Experience
  • Abbildung 42

    ©1997,T.Hofmann

     







    Die Abbildung stellt einen Screenshot des Fensters der Anatomie-Experience dar.

    Legende:

    1 = Imagemap

    2 = VRML-Szene

    3 = textAusgabe1

    4 = textAusgabe2

    5 = Platzhalter für

    vrmlObserver-Applet

    6 = Frame thread2

    7 = Frame thread3

  • Rotation des Fußknochens in der VRML-Szene
  • Abbildung 43


    ©1997,T.Hofmann









    Die Abbildung zeigt eine Serie von Screenshots. Dargestellt wird die Rotation des Fußknochens in der VRML-Szene. Die Rotation wird durch den Benutzer ausgeführt.

    Kommunikation der Komponenten

    Die eingebetteten Elemente kommunizieren angetrieben durch die LiveConnect Technologie miteinander. Bevor auf die eigentliche Funktionsstruktur der Lernsoftware eingegangen wird, ist es wichtig zu verstehen in welchen kommunikativen Zusammenhang die einzelnen Elemente zueinander stehen.

    Das Diagramm in Abbildung 44 zeigt die eingebetteten Elemente als Blöcke. Die Pfeile geben an in welche Richtung eine Kommunikation stattfindet, also welches Element steuert bzw. gesteuert wird. Der JavaScript-Funktionsblock beispielsweise spricht die Applets textAusgabe1 und textAusgabe2 an, eine Rückantwort findet jedoch nicht statt. Die Kommunikation ist unidirectional. Im konkreten Fall wird das Applet von einer JavaScript-Funktion angewiesen, einen Text darzustellen. Im Vergleich dazu kommuniziert das vrmlObserver.class Applet mit der VRML-Szene bidirectional. Es sendet Anfragen bezüglich Objektinformationen an die 3d-Szene und verarbeitet anschließend die Antworten weiter.

  • Kommunikationsfluß zwischen den Funktionselementen
  • Abbildung 44

    ©1997,T.Hofmann












    Das Diagramm zeigt alle für die Anwendung notwendigen Elemente. Die Pfeile geben die Richtung des Informationesflusses an. Nur zwischen Elementen, die auch direkt über Pfeile verbunden sind findet auch tatsächliche eine Kommunikation statt. Diese Kommunikation ist entweder uni- oder bidirectional.

    Datenstrukturierung

    Mit Kenntnis um die Zusammenhänge im Bezug auf die Kommunikation zwischen den einzelnen Elementen, kann mit einer Erklärung der Dokumentenorganisation fortgefahren werden. Zunächsteinmal ist der grobe Ablauf beim Laden der Software zu erläutern. Die Abbildung 45 stellt diesen Vorgang grafisch dar.

  • Hierarchischer Aufbau der Dokumente und Elemente
  • Abbildung 45

    ©1997,T.Hofmann



































    Zusammenhang zwischen HTML-Dokumenten und eingebetteten Elementen

    Mit Auswahl der Sprache im Leitdokument, wird im entsprechenden Pfad eine Datei index.htm aufgerufen, welche die Systemvoraussetzungen für die korrekte Ausführung der Anwendung prüft, und dem Benutzer wenn nötig Fehlermeldungen mit Lösungsvorschlägen bereithält.

    Ist diese Datei abgearbeitet, folgt das Laden der Datei loader.htm in einem neuen Browserfenster. Die Datei beinhaltet ein Framesset mit 2 Framebereichen. In den Frame thread2 wird ein Dokument mit den Elementen für die Benutzerkommunikation geladen. Der Frame thead3 enthält die Datei mit Verweisen auf Elemente für die VRML-Szene und einem Applet zur Überwachung der Szene.

    Sowohl das Applet für die Textausgabe, als auch das vrmlOberserv.class-Applet und das foot.wrl-File mit den VRML-Daten ist unabhängig von der gewählten Sprache entwickelt worden. Dadurch wird zum einen Entwicklungsarbeit und zum anderen Speicherkapazität auf dem Webserver gespart. Außerdem gestaltet sich die Verwaltung von Versionsnummern einfacher, da nur ein Satz von Applets und 3d-Modellen in einem einzigen Pfad gespeichert ist. Die Imagemap und Hintergrundgrafiken werden durch ein JavaScript automatisch geladen und anschließend angezeigt. Nach Beendigung des Ladevorganges werden die Applets und die VRML-Szene initialisiert und die Anwendung ist bereit um Eingaben den Lerners durch anklicken eines Schaltfeldes in der Imagemap zu empfangen. Die nun folgenden Ausführungen beziehen sich auf die deutschen Sprachdialoge. Aus den oben erläuterten Gründen ist der Funktionsablauf für die englische Ausgabe gleich gestaltet.

    Optionen der Imagemap

    Mit der ClientSide-Imagemap hat der Lerner verschiedene Optionen um Funktionen auszuführen. Jeder Button verweist auf eine JavaScript-Funktion eingebettet im Dokument thread2.htm. Im folgenden sind die einzelnen Schaltflächen und die damit verlinkte Funktion kurz erläutert:

     

    Intro gibt dem Benutzer eine kurze Einführung zum Programm, in einem neu aufgerufenen Fenster wird das Dokument intro.htm geladen. Über die Schaltfläche "schließen" wird dieses Fenster geschlossen und der Fokus an das Hauptfenster zurück gegeben.
     

    Hilfe gibt dem Lerner Hilfestellungen zur Benutzung und Funktionsweise der Anatomie-Experience, sowie Hinweise zu bekannten Fehlern in der Ausführung. Es wird die gleiche JavaScript-Funktion wie für Intro für das öffnen eines neuen Fensters aufgerufen, als Übergabeparameter wird auf das Dokument hilfe.htm verwiesen.
     

    Ende zeigte eine Dialogbox und schließt letztendlich das Fenster mit der Anatomie-Experience. Der Fokus wird dann auf das Fenster, von welchem die Anwendung aufgerufen wurde, zurück gesetzt.
     

    Feedback ist ein Verweis auf eine Emailadresse. Der Browser wird dadurch angehalten, eine neue Email mit angegebenen Adressaten in der Adresszeile zu kreieren. Als Subjekt wird automatisch der Text "Feedback zur Anatomie - Experience V1.0" eingesetzt. Der Lerner hat dann die Gelegenheit einen Kommentar an den Entwickler abzugeben.
     


    Start gibt denn Anstoß für das Ausführen des wesentlichen Kerns der Lernsoftware, dem Abfragemodul.

    Die Konzepte und Funktionsstrukturen für HILFE, INTRO, ENDE und FEEDBACK sollen im einzelnen nicht weiter beschrieben werden. Der Interessierte Leser sei hier auf die Kommentare und den Programmcode in der Datei thread2.htm im Pfad ../anatomy/english/ bzw. ../anatomy/german/ verwiesen. Da das Abfragemodul den eigentlichen Kern der Anwendung darstellt wird dessen Funktionsablauf genauer untersucht.

    Funktionsablauf für die Objektabfrage

    Analog zur Strukturierung des Browserfensters in zwei getrennteFramebereiche ist das Abfragesystem in zwei Hauptmodule unterteilt. Das im Frame thread3 gelagerte VRML-MODUL besteht aus der VRML-Szene und dem vrmlObserver.class Applet. Außerdem sorgt ein JavaScript für einen Funktionsaufruf im Frame thread2, dem FRAGE-MODUL. Zu diesem Modul gehören diverse JavaScriptfunktionen für die Auswahl von Fragen und der "Antworten"-Auswertung und zwei Applets für die Textausgabe auf der WebSeite.

    Im VRML-MODUL läuft eine kontinuierliche Abfrage von Eigenschaften der VRML-Welt ohne zutun durch Programmteile des FRAGE-MODULS ab. Das JavaApplet prüft dabei, ob ein Objekt in der Szene angeklickt wurde. Ist dies der Fall, dann vergleicht es dieses mit denen über die Parameterliste geladenen Namen für die Knochenpartien. Findet es in dieser Liste eine Übereinstimmung, ruft es die Funktion linkclick() im Dokument auf und übergibt den Objektnamen als Parameter. Die linkclick()-Funktion wiederum sendet den Objektnamen an die Funktion auswerten() im thread2.

    Das FRAGE-MODUL wird auf zwei Wegen aktiv. Möglichkeit Nummer eins ist die Aktivierung der Abfrage durch den Benutzer über das START-Schaltfeld. Mit Beginn des Abfragemodus wählt eine Funktion zufallsbedingt aus der in einem Array geladenen Objektnamen (Knochennamen) einen beliebigen aus und sendet eine Textnachricht mit der Aufforderung an den Benutzer an das Applet textAusgabe1. Anschließend geht es in einen Schlafmodus über. Dieser Schlafmodus wird entweder wieder verlassen, sobald die Funktion auserten() vom VRML-MODUL gestartet wird. Es wird nun entschieden, ob die Abfrage generell schon gestartet ist. Dies ist hier der Fall, woraufhin der vom FRAGE-MODUL gewählte Objektname mit dem übergebenen Wert verglichen wird. Ist der Wert nicht gleich, wird eine entsprechende Meldung über textAusgabe1 und textAusgabe2 an den Lerner gegeben, mit der Aufforderung das richtigen Objekt zu finden und der Inhalt der Variable für die Anzahl der Versuche um eins erhöht. War der Wert allerdings gleich, dann wird die Frage als beantwortet markiert und die Anzahl der Versuche festgehalten.

    Das Fragespiel beginnt wieder von neuem mit einem neuen Objektnamen. Sind alle Objektnamen in der Liste mit beantwortet markiert, dann bereitet die Funktion abfrageroutine() die Auswertung der Abfrage vor und zeigt sie in einem neuen Fenster an.

    Die kontinuierliche Prüfung der VRLM-Szene ist nur durch die Implementierung eines Threads im vrmlObserver.class Applet möglich. Würden in einer JavaScript-Funktion über eine Schleife die Eigenschaften abgefragt werden, dann wäre die Browsersoftware nicht mehr in der Lage Aktionen des Benutzer entgegen zu nehmen. Aus diesem Grund wurde die Auswertung und Fragestellung im FRAGE-MODUL mit der beschriebenen Methode vorgenommen, bei der Funktionen nur bei bedarf aktiviert werden. Alle Zustände des Lernsystems müssen dabei zu jederzeit über Variablen festgehalten werden.

    In der Abbildung 46 wird der beschriebene Funktionsablauf noch einmal auf grafischem Wege dargelegt.

  • Funktionsablauf der Objektabfrage und Auswertung
  • Abbildung 46

    ©1997,T.Hofmann































    Struktureller Ablauf der Funktionen im FRAGE-MODUL. Die Abfrage wird vom Benutzer durch Drücken der START-Schaltfläche aktiviert.

    Betrachtung des vrmlOberserver.class Applets

    Wegen der nach Außen hin offenen Gestaltung des vrmlObserver.class-Applets soll die Funktionsweise und Parametrisierung kurz genauer erläutert werden, um die Wiederverwendung für andere Projekte zu erleichtern. Implementiert wird das Applet in einem HTML-Dokument durch den applet-Tag. Das folgende HTML-Beispiel für die Implementierung soll die möglichen Optionen und Parameter aufzeigen, welche die Eigenschaften des Applets beeinflussen. Die fettgedruckten Namen müssen genau wie dargestellt geschrieben sein, die kursiven Werte sind beliebig wählbar:

      <applet HTML-Tag, der die Implementierung einleitet
      name=optionalerName Name des Applets, über den es von anderen Elementen angesprochen werden kann, diese Option ist nicht zwingend notwendig
      code=vrmlObserver.class Name der Klassendatei
      codebase="../pfadname/" Optionaler Verweis auf die Lage der Klassendatei auf dem Webserver
      width=20 height=20 Größe des Bereichs, der für das Applet im Dokument reserviert wird. Weil das Applet keine Informationen auf dem Bildschirm ausgibt wurden kleine Werte gewählt.
      MAYSCRIPT> Diese Option erlaubt es Java auf JavaScript-Code im HTML-Dokument zuzugreifen.
      <param name=ObjectCount value= N> N ist die Anzahl der Objekte in der VRML-Szene
      <param name=Object1 value="Objektname 1"> Der erste Objektnamen ist entsprechend der Definition im VRML-File einzusetzen.
      <param name=ObjectN value="Objektname N"> Abhängig von der Zahl N aus dem ObjectCount-Parameter müssen N Objekte parametrisiert werden.
      </applet> Schließen des applet-Tags

    Die Objektnamen im Parameter Object# sind in der VRML-Datei durch den DEF-Node festgellegt. Dieser Node ist der Container für ein 3D-Objekt. Es sei folgender Node gegeben:

    DEF Phalanx_Distalis_5 IndexedFaceSet {

    ...

    }

    Definiert wird hier der Knochen (das Objekt) mit dem Namen Phalanx_Distalis_5. Um dem Applet die Existenz dieses Knochens mitzuteilen muß der Parameter:

    <param name=Object# value="Phalanx_Distalis_5">

    gesetzt werden. Wichtig ist, daß die Schreibweise im Parameter exakt mit der Definition im DEF-Node übereinstimmen muß, da sonst die Szene nicht richtig initialisiert werden kann, sprich das gewünschte Objekt kann nicht angesprochen werden. Für # wird eine Zahl aus 1 bis N gewählt.

    Netscape hat sich bei der Implementierung der Objektbehandlungsmethoden in der Live3d-Klassenbiliothek auf die wichtigsten Funktionen beschränkt. Deshalb ist gegenwärtig eine Methode für die Bestimmung des Objektnamens eines angeklickten 3D-Objektes in einer Szene vorgesehen, jedoch noch nicht realisiert.

    Neben dem Applet und der VRML-Szene muß außerdem eine JavaScript-Funktion mit dem Namen linkclick() im Dokumenten vorhanden sein. Diese Funktion wird vom JavaApplet aufgerufen nachdem ein eindeutig erkanntes Objekt in der 3D-Szene angeklickt wurde. Als Übergabeparameter wird der Name des Objektes, wie er im Parameter des Applet-Tags definiert wurde geliefert. Um den Parameter weiterverarbeiten zu können, muß ein Platzhalter dafür in der Funktion vorgesehen sein. Mit dem obigen Beispiel für den DEF-Node sieht die Funktion wie folgt aus:

    linkclick (objektname) {

    ...

    }

    In diesem Beispiel ist objektname eine Variable, die wegen der Übergabe einer String-Variable automatisch als String definiert wird und innerhalb der Funktion ansprechbar ist. Noch nicht im Applet implementiert ist eine Möglichkeit, den Namen der Funktion als Parameter zu übergeben um so mehr Flexibilität zu schaffen.

    Weitere Definitionen sind für die korrekte Ausführung nicht notwendig, da das Applet alle notwendigen Informationen um die VRML-Szene anzusprechen automatisch von der Browsersoftware anfordert.

    Anzumerken ist, daß das vrmlObserver.class-Applet ein Live3d-Plugin und Navigator ab Version 3.0 Beta4 wegen dessen LiveConnect Unterstützung benötigt. Der Einsatz mit anderen Web- bzw. VRML-Browsern ist nicht möglich. Eine entsprechende Fehlerbehandlung sollte deshalb beim Einsatz dieses Applets bedacht werden.

    5.2.3 Implementierungsprobleme

    Entwurf von 3d-Objekten

    Im 3D-Studioformat sind als Freeware 3D-Objekte der menschlichen Anatomie im Internet verfügbar. Es zeigt sich allerdings, daß die Modelle meist nur als ein einziges Objekt mit einer Vielzahl von Polygonen aufgebaut sind. Für die entwickelte "Experience" ist dies jedoch nicht ausreichend, da jeder Knochen für sich ansprechbar sein muß. Um dies zu erreichen ist es notwendig, die Polygonzüge so aufzuteilen, daß das vorhandene Objekt in viele Einzelobjekte differenziert wird. Für den Fußknochen bestand die Aufgabe darin, ca. 1500 Polygonzüge zu gruppieren. Das Ergebnis war dann ohne großen Aufwand in das VRML-Format konvertierbar.

    Für eine Lernsoftware, welche die gesamte menschliche Anatomie umfaßt, ist dies ein unrealistischer Weg. Es bietet sich dann an, die Modell als kommerzielles Produkt zu kaufen.

    Entwicklung mit Live3d und LiveConnect

    Für die im Herbst '96 entwickelte Live3d und LiveConnect Technologien gab es zu Beginn des Projektes keine Dokumentation. Dem eigentlichen Einsatz gingen deshalb mehrere Testanwendungen voraus, um die Möglichkeiten und Grenzen zu erörtern.

    Es stellte sich heraus, daß einige für die Interaktion mit einer 3d-Szene wichtige Funktionen in der Live3d-Bibliothek noch nicht implementiert sind. Unter anderem ist dies die Methode getName(), welche den Namen eines Objektes mit dem es im Node DEF der VRML-Datei definiert ist als String zurück liefert. Um bestimmen zu können, welches Objekt angeklickt wurde ist dies jedoch im Zusammenhang mit der onMouseClick() Methode notwendig.

    Als Ausweg wurde der Anchor-Node eingeführt, welcher über die Methode onAnchorClick() abfragbar ist. Lokal ist dies ohne Probleme anwendbar und die Applikation lief einwandfrei. Über einen Webserver wird der Anchor-Node als Hyperlink interpretiert, d.h. beim anklicken wird versucht ein Dokument zu laden. Ergebnis ist, daß in der 3d-Szene eine Fehlermeldung ausgegeben und die Applikation angehalten wird.

    Weiter Methoden für die Bestimmung aktivierter Objekt sind in der Live3d-Bibliothek nicht vorgesehen. Letztlich wurde deshalb die Definition über onMouseClick() gewählt, wobei die Objekte der Szene über eine Parameterliste an das JavaApplet übergeben werden. Das Applet initialisiert die Parameter als Objekte und legt sie in einem Array ab. Die onMouseClick()-Methode liefert dann beim Aufruf dieses EventHandlers einen Wert für das angeklickte Objekt zurück. Dieser Wert wird dann mit den zuvor definierten Objekten verglichen und ein entsprechendes Ergebnis weiterverarbeitet.

    Syncronisationsprobleme von Ladevorgängen

    Für die Kommunikation zwischen Elementen auf einer Webpage hat sich LiveConnect als eine hilfreiche Technologie erwiesen. Probleme bereitet die Initialisierung größerer Datenmengen. Konkret gab es Schwierigkeiten mit dem JavaApplet vmrlObserver.class , welches für die Abfrage des angeklickten Objektes in der 3d-Szene zuständig ist. Um alle Objekte erkennen zu können, müssen diese bei der Initialisierung des Applets bereits in der Szene anwesend sein. Die Szene als solches wird bereits beim Laden initialisiert, also für das Applet als VRML-Szene erkennbar. Dies gilt jedoch nicht für die darin enthaltenen Objekte, welche erst nach dem Laden der Datei ansprechbar sind. Im ungünstigsten Fall erkennt das Applet dann die Szene, initialisiert jedoch keines der Objekte. Beim Anklicken eines Objekte in der Szene wird verglichen, ob es mit einem der zuvor initialisierten Objekten identisch ist. Die Antwort wäre somit nein und die Anwendung funktioniert nicht.

    Behoben wurde diese Problem durch die weiter oben beschriebene Methode zur Objektdefnition. Da die Objekte nicht mehr anhand der tatsächlich in der Szene vorhandenen Objekte initialisiert werden, sondern über eine Parameterliste an das Applet gegeben werden, sind zeitabhängige Initialisierungsprobleme ausgeschlossen. Dies setzt aber voraus, daß dem Entwickler alle Objekte bekannt sind um sie explizit zuweisen zu können. Es steht zur Debatte, ob nicht der Medientracker von Java verwendet werden könnte um eine Synkronisation zwischen dem vrmlObserver.class-Applet und der 3d-Szene zu verwalten.

    5.2.4 Anregungen für Verbesserungen

    Die Anatomie-Experience ist nur ein kleiner Teil dessen, was eine vollwertiges Anatomielernsystem ausmacht. Entsprechend umfrangreich sind auch die Anregungen für weitere Entwicklungen.

    Screendesign und Benutzerschnittstelle

    In Feedback haben einige Anwender die Benutzerführung kritisiert. Es sei nicht möglich zu erkennen, ob das System auf Benutzereingaben reagiere oder nicht. Tatsächlich ist dies ein Punkt, der verbessert werden sollte. Stürzt zum Beispiel ein JavaApplet während der Abarbeitung ab, dann erhält der Benutzer keine Meldung über den momentanen Zustand des Systems. Gleiches gilt für das nicht gestartete Applets, was gelegentlich vorkommen kann. Idealerweise sind Anweisungen und Hilfestellungen besser im Screendesign oder in der 3d-Szene integriert, als sie in der Statuszeile darzustellen. Denkbare wäre zum Beispiel eine sich ändernde Farbe für angewählte Knochen, die wieder auf den Ausgangszustand zurück gesetzt wird, sobald ein anderer Knochen angeklickt wurde.

    Ein weiterer Kritikpunkt ist der, daß Linkfelder in den Grafiken nicht als solche gleich zu erkennen sind. Durch entsprechende Gestaltung können diese Felder als Schaltflächen kenntlich gemacht werden. Durch eine JavaScript-Funktion, die beim Anklicken mit der Maus zwischen zwei Grafiken hin und her schaltet und eventuell noch mit einem Sound unterlegt, kann der Effekt noch unterstrichen werden.

    Durch eine Soundunterstützung könnten die Anweisungen bzw. Namen der Knochen in Form von gesprochenem Text ausgegeben werden. Mit reduzierter Qualität und der Pre-loading-Methode, wie sie unter 5.1.2 Beschleunigung der... beschrieben wurde ist dies mit kleinen Sounddateien und schnellen Ladezeiten zu verwirklichen. Der Lerner hätte dann den Vorteil, vor allem die lateinischen Bezeichnungen so zu hören, wie sie auch tatsächlich ausgesprochen werden. Versuche, Sprache mit einem Programm künstlich zu erzeugen wurden mit rsynth durchgeführt. Ein auf dem Webserver installiertes Programm wandelt dabei eine von einem JavaApplet gesendeten Text in künstliche Sprache um und sendet diese als Audioformat gespeichert an das Applet zurück, welches anschließend dieses File abspielt.

    Qualitativ ist diese Methode durchaus akzeptabel. Probleme bereitete jedoch die Responsetime des Webservers, die je nach Last störend wirkte. Besser wäre es daher die Sprachgenerierung in einem Applet oder über ein Plugin durchzuführen.

    Inhalt

    Die Versuchsversion ermöglicht es dem Lerner lediglich einen Abfragemodus zu benutzen. Die Implementierung eines Lernmodus um durch Anklicken oder Zeigen auf den Knochen deren Namen zu lernen und zusätzliche Informationen zu erhalten ist notwendig, bevor von einer vollwertigen Lernsoftware gesprochen werden kann.

    Auch der Modellbestand ist noch mindestens auf ein komplettiertes menschliches Skelett zu erweitern. Um die Datenmengen in kurzer Zeit übertragen zu können, ist es ratsam das Skelett in Regionen, d.h. Teildateien zu separieren.

    Technisches Design

    Wie aus der Funktionsbeschreibung des Abfragemoduls zu erkennen, wird der Kurs mit dem drücken der START-Schaltfläche auch dann gestartet, wenn der Lerner gerade mitten in der Beantwortung ist. Dies sollte so abgeändert werden, daß nach dem Start der Abfragefunktion die Schaltfläche umschaltet auf ABFRAGE BEENDEN und eine entsprechende Auswertung nach dem Anklicken die Abfrage nicht neu startet. Der Benutzer sollte vielmehr zu einer nochmaligen Bestätigung für den Abbruch, in einer Dialogbox auffordert werden.

    Die Gelegenheit für den Benutzer, ein Feedback in Form eines Emails abzusenden, hat sich als lohnend gezeigt. Allerdings fällt es dem Benutzer manchmal schwer gerade technische Hard- und Softwarebedingungen auf seinem System genau zu definieren. Für diesen Zweck wäre es gut ein Feedback-Sheet mittels Formularen zusätzlich bereitzustellen. Dort könnte ein JavaApplet oder eine JavaScript-Funktion Systemdaten wie Betriebssystem, Browserversion, installierte Plugins etc. sammeln und automatisch per Email versenden. Eine präzise Methode, um Kenntnisse über die Benutzerstrukturen zu sammeln, die auch für weitere Entwicklungen von Bedeutung sind.

    Die gegenwärtige Version der Lernsoftware setzt Netscapes Navigator als Browsersoftware voraus. Um einem größeren Publikum den Zugang zur Anwendung zu ermöglichen, wäre es wichtig die Anwendung mindestens auf den Microsoft InternetExplorer zu erweitern. Zu untersuchen ist dabei ob:

    5.3 Die Softwaretest-Routine

    5.3.1 Einführung

    Die für beide Anwendungen eingesetzten Datei check.htm bzw. index.htm sind nichts anderes als ein JavaScript, welches die Browsersoftware und Plugins auf die notwendigen Voraussetzungen für die korrekte Ausführung überprüft. Werden die Voraussetzungen nicht erfüllt, so wird an den Benutzer ein Hinweis gegeben, wie er weiter zu verfahren hat.

    Ermöglicht wird das Prüfen von Softwarekomponenten durch die Erweiterungen, welche JavaScript in der Version 1.1 erfahren hat. Neben der Browserversion läßt sich auch jedes installierte Plugin auf Existenz und Version kontrollieren. Durch den JavaScript-Befehl document.write() ist es zudem möglich ohne erneutes nachladen von Dokumenten Informationen in einem Browserfenster auszugeben.

    Abbildung 47 zeigt ein Beispiel für die Fehlerausgabe bei fehlender JavaScript Version 1.1-Unterstützung.

  • Beispiel für die Fehlerausgabe der Softwaretest-Routine
  • Abbildung 47

    ©1997,T.Hofmann









    Screenshot zeigt ein Beispiel für die Fehlerausgabe der Softwaretest-Routine. Ein Fehler wurde hervorgerufen, da die verwendete Version der Browsersoftware (MS Internet Explorer 3.0) JavaScript1.1 nicht unterstützt.

    5.3.2 Funktionsschema

    Das Funktionsschema für beide Anwendungen ist in etwa gleich und läßt sich deshalb in einem Diagramm darstellen. Lediglich bei der Abfrage einiger Plugins und den daraus resultierenden Fehlerausgaben gibt es Unterschiede, was jedoch im Funktionsschema nicht zum Tragen kommt. Abbildung 48 zeigt die Funktionsstruktur der JavaScript-Funktion.

  • Funktionsstruktur der JavaScript-Funktion in der Datei index.htm
  • Abbildung 48

    ©1997,T.Hofmann

















    Die JavaScript-Funktion wird nach dem Laden des Dokumentes automatisch gestartet.

    Im Kopf werden alle Fehlermeldungen als Variablen definiert um später nach dem Baukastenprinzip zu einem kompletten HTML-Dokument "on-the-fly" zusammen gebaut zuwerden.

    Browsername und Version werden abgefragt und mit einem Zahlencode in einer Variable abgelegt. Das benötigte Plugin wird auf Existenz geprüft und ein entsprechender Zahlencode generiert.

    Die abgefragten Werte werden dann ausgewertet. Wird das Fehlen des Plugins, der Java und JavaScript1.1 Fähigkeit festegellt, werden die Fehlerdokumente erstellt und ausgegeben.

    Ist der Entscheidungspfad fehlerfrei durchlaufen, wird die Anwendung gestartet.

    Der Programmcode zu diesem Funktionsschema ist im Anhang unter Programmcode-Auszug zu finden. Die Namen der Dateien lauten index.htm (für die Anatomy-Experience) bzw. check.htm (für den Webkurs). Eine Umfangreiche Erläuterung aller Programmpunkte, würde wegen der Menge an Programmteilen, über den Umfang dieser Arbeit weit hinausgehen.

    5.3.3 Implementierungsprobleme

    Die Realisierung der Funktionen gestaltete sich denkbar einfach. Mit der Methode navigator.propertyName lassen sich sich Plugins, die Browserversion und Javaunterstützung durch den jeweiligen propertyName abfragen. Die Abfrage navigator.plugins["Shockwave"] zum Beispiel liefert als Wert 1 zurück wenn ein Plugin mit dem Namen Shockwave installiert ist.

    Problematisch ist allerdings die Bestimmung des richtigen Plugin-Namens. Zwar lassen sich im Navigator die installierten Plugins über den Befehl about:plugins auflisten, jedoch erst nach langem ausprobieren wurde festgestellt, daß der Name über den ein Plugin angesprochen werden kann die vollständige fettgedruckte einleitende Bezeichnung inklusive aller Leerzeichen ist. Die von Netscape erhältlichen Dokumentation schweigt sich in dieser Hinsicht aus. Als Konsequenz ergibt sich damit, daß verschiedene Versionen eines Plugins unter Umständen mit unterschiedlichen Namen registriert sind und daher auch alle etwaigen Namen in einer Abfrage explizit angegeben werden müssen.

  • Darstellung der about:plugins-Informationen im Netscape Navigator
  • Abbildung 49

    ©1997,T.Hofmann









    Screenshot der about:plugins-Anzeige im Netscape Navigator3.01 unter Windows95.

    Der Name des Plugins ist "Live3D". Außer dem Namen werden Angaben über Mime-Type und Dateinamen ausgegeben.

    5.3.4 Anregungen für weitere Funktionen

    Um eine vielseitigere Anwendung zu ermöglichen, wäre es notwendig die JavaScript-Funktionen um zugestalte bzw. zu erweitern. Die modulare Struktur unterstützt diesen Ansatz bereits. Ideal wäre eine multifunktionales Fehlerscript, das grundsätzlich alle Funktionen abfragen bzw. die installierten Plugins bestimmen kann. Über Funktionsparameter ist es möglich der Funktion benötigte Funktionen und Plugins bzw. deren Namen und zugehörige Fehlermeldungen mitzuteilen.

    Statt über Funktionsparameter könnten die Informationen auch in Variablen abgelegt werden, die dann nur den gegebenen Verhältnissen angepasst werden müßten.

    5.4 Verwendete Entwicklungstool

    Um einen Überblick zu geben, welche Entwicklungswerzeuge bei der Realisierung einer WWW-Anwendung Verwendung finden, wurde die folgende Liste zusammengestellt. Neben den Produkten selbst werden deren Anwendungsbereich und eine Bezugsquelle aufgeführt.

    Im Einzelnen kamen folgende Produkte zum Einsatz:

    Übersicht der verwendeten Entwicklungstools Tabelle 4

    ©1997,T.Hofmann

     

    5.5 Erkenntnisse

    Der Kerngedanke des Tutorial war die Entwicklung eines HMTL-basierten WBTs, jedoch ohne der traditionellen Seitenorientierung zu folgen, sondern einen neuen Ansatz über die Bildschirmorientierung zu begehen. Für die Anatomie-Experience war das Hauptziel die Verwirklichung eine Lernsimulation mit 3D-Elementen unter Verwendung standardmäßiger Hardwarevoraussetzungen.

    Die gesteckten Ziele wurden erreicht. Trotzdem sind im Bereich der Lernsystementwicklung für das Internet sind noch eine Fülle von ungelösten Problemen vorhanden. Neben fehlenden Werkzeugen speziell für die Realisierung von webbasierten Lernsystemen, sind vor allem die Abstimmung auf verschiedene Betriebssysteme und Browsersoftware für längeren Entwicklungszeit als bei einer CD-ROM basierten Anwendungen verantwortlich. Ferner sind Technologien wie LiveConnect oder VRML noch nicht soweit ausgereift, als daß ein reibungslosen Einsatz zu gewährleisten wäre. Hinzu kommt dann meist auch noch der Mangel an entsprechender Dokumentation.

    HTML2.0 ist in Verbindung mit CGI-Scripten ein stabiles System und vor allem auch kompatibel mit allen gängigen Browsern und Betriebssystemen. Die funktionellen Möglichkeiten werden aber durch Nachteile wie fehlende Unterstützung für Multimedia und interaktive Komponenten erkauft.

    Es hat sich auch gezeigt, daß eine Lernsoftware für webbasierte Anwendungen in angemessener Zeit von einer einzelnen Person nicht oder nur mit Einschränkungen im Umfang und Funktionalität der Software erstellt werden kann. Im Hinblick auf die fachliche Kompetenz, sind eigentlich mindestens 3 Personen für die Entwicklung notwendig. Ein Didaktiker für die Kursaufbereitung, ein Designer für die gestalterischen Aufgaben und ein Programmier um interaktive Elemente zu verwirklichen. Ob ein Einzelner alle drei Gebiete soweit abdecken kann, daß das Endprodukt nicht darunter leidet, ist fraglich.

    Vielfach nicht beachtet sei am Rande noch ein allgemeines Problem beim Einsatz von ProxyServern genannt. Um Ihre Bandbreiten zu schonen, setzten viele Provider heute ProxyServer ein. Ein ProxyServer ist nicht anderes als ein großer Cache auf Seiten des Internetproviders. Fordert ein Benutzer eine HTML-Seite an, so sieht der ProxyServer zuerst auf der eigenen Festplatte nach, ob diese Seite schon einmal angefordert wurde. Ist dies nicht der Fall, dann holt er die entsprechende Information für den Benutzer aus dem Internet und speichert sie auf der eigenen Festplatte ab. Greift ein Benutzer nochmals auf diese HMTL-Seite zu, dann wird der Proxy die bereits gespeicherte Seite zuschicken. Unter Umständen sind die Informationen dann nicht mehr Aktuell. Nicht jeder ProxyServer aktualisiert oder löscht ältere Datenbestände. Abhilfe ist das Abschalten der ProxyServer Unterstützung in der Browsersoftware. Einige Internetprovider geben allerdings ausschließlich über einen ProxyServer Zugang zum Internet. In diesem Falle hilft dann nur das Drücken des Reload-Buttons.

    Werden allerdings in einer Lernsoftware die Menüleiste und Buttons ausgeblendet, ist ein Reload nicht mehr möglich. Der Vorteil des immer aktuellen Kursinhaltes durch die Bereitstellung im Internet geht für Benutzer dieser Kategorie verloren und ist als ernst zunehmendes Problem anzusehen.

    In Abbildung 50 wird abschließend Bezug der entwickelten Anwendungen zu den Lerntheorien hergestellt. Rot gezeichnet ist der Bereich zu sehen, den die WBTs allgemein abdecken. Das Tutorial - Der Weg zur besseren Homepage - ist im Bereich des Lernstufenmodells eingeordnet. In der Abbildung mit Zyan dargestellt. Dem Lerner werden im Kurs Regeltexte mit dem Hintergedanken vorgestellt, daß er sich ein inneres Bild aufbaut. Unterstützt wird dies durch interaktive Beispiele und Grafiken, was auch in den Bereich der Lernstufen Signallernen und Reiz-Reaktions-Lernen fällt. Die Wissenskontrolle deckt zudem den behavioristischen Teil dieser Theorie ab.

    Die Anatomie-Experience ist im Entwicklungsstadium mit Ende dieser Arbeit am ehesten dem Computermodell zuzuschreiben. In der Abbildung ist dies Blau eingezeichnet. Durch geänderte Kodierung der Darstellungsweise von 2 dimensionalem Papier zu 3 dimensionalem Modell wird versucht, den Transfer von Kurz- zu Langzeitgedächnis zu erleichtern.

  • Beispiel WBTs und die Lernmethoden bzw. Lerntheorien.
  • Abbildung 50

    ©1997,T.Hofmann




    Es ist anzumerken, daß die Anwendungen bzw. Teilbereiche auch in anderer Weise den Lernmodellen untergeordnet werden können. Das Drill and Practice WBT ist auch dem operanten Lernen zuordenbar. Als Reaktion kann das Finden der Knochen definiert werden, als Reiz das Anzeigen der benötigten Versuche. Auch beim Tutorial ist eine Einordnung in andere Bereiche denkbar. Es zeigt sich also, daß eine klare Definition welchen Bereichen ein WBT nun genau zugeordnet werden muß, nicht möglich ist. Die Einteilung ist vielmehr Abhängig von der Interpretation der Lerntheorien durch den Entwickler.