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
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:
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:
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:
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.
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. |
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.
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. |
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.
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.
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.
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.
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.
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.
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:
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. |
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. |
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:
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.
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.
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:
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
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.
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.
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 |
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.
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.
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.
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:
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.
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. |
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.
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. |
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.
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 |
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.
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.