Designstudie zum Screencapturing für ein Autorentool zur Erstellung von Lerninhalten auf Mobilgeräten

Inhalt

Zusammenfassung

1. Einleitung
1.1. Ausgangslage
1.2. Aufgabenbeschreibung
1.3. Arbeitsprozess
1.4. Aufbau der Arbeit

2. Capturingmethoden
2.1. Kapitelübersicht
2.2. Screencapturingtools
2.2.1. Testfeld und Testverfahren
2.2.2. Testergebnisse
2.2.3. Fazit
2.2.4. Möglichkeiten der Integration in ein Autorentool
2.3. Digitalfotografie
2.4. Weitere Capturingalternativen
2.4.1. Proprietäres Capturing
2.4.2. Emulatoren
2.5. Bewertung der Screencapturingmethoden

3. Anforderungsanalyse
3.1. Ist-Zustand
3.2. Zielgruppe
3.3. Anforderungskatalog der SM
3.4. Weitere Anforderungen der SM
3.5. Selbstgesetzte Anforderungen

4. Konzept
4.1. Use Cases - Grob
4.2. Directory-Poller
4.3. Komponenten

5. Design
5.1. GUI für Lernende
5.1.1. Hauptansicht für Lernende
5.1.2. Alternativansicht für Lernende
5.2. GUI für Autoren
5.2.1. Alternativansicht
5.2.2. Hauptansicht für die Primärsprache
5.2.3. Grafikbearbeitungsfunktionalität
5.2.4. Hauptansicht für die Sekundärsprache

6. Spezifikation
6.1. Komponentenstruktur
6.2. Prozessdiagramme
6.3. Use Cases - fein
6.3.1. Use Cases - Autoren
6.3.2. Use Cases - Lernende

7. Hinweise zur Umsetzung
7.1. Hardwaretechnische Umsetzung
7.2. Softwaretechnische Umsetzung

8. Aufwandsvergleich

9. Weitere Konzepte
9.1. Lernkontrolle
9.2. Automatisch erstellte Animationen
9.3. Einbindung in andere Lernumgebungen
9.4. Simulationen
9.5. Lernen am Mobilgerät

10. Resümee

A. Unterlagen von SM

B. Ausgelagerte Fotos

C. Ausgelagerte Tabellen

D. Use Cases

Abbildungsverzeichnis

Tabellenverzeichnis

Quellenverzeichnis

Zusammenfassung

Bei dem schweizerischen Mobilfunkanbieter SM¹ besteht Bedarf an Schulungsunterlagen für Mobilgeräte, die Screenshots enthalten. Diese werden mittels Screencapturingtools auf den Geräten erstellt und umständlich mit mehreren Programmen in das Schulungsmaterial
integriert. Die Tools selbst sind teilweise sehr fehlerbehaftet und es existiert keine plattformunabhängige Lösung.

Ziel der Arbeit ist, verschiedene Möglichkeiten des Screencapturings zu evaluieren und die für die SM beste zu bestimmen. Insbesondere ist das Capturing mittels Digitalfotografie auf Machbarkeit zu untersuchen. Weiterhin soll ein Autorentool spezifiziert werden, dass technischen, wie auch didaktischen und methodischen Anforderungen entspricht und die ausgewählte Screencapturingmethode integriert.

1. Einleitung

1.1. Ausgangslage

Die Studienarbeit wurde in Kooperation mit der SM und der MAGH UND BOPPERT GMBH durchgeführt.

Für die SM ist die Schulung der Mitarbeiter im Customer Care auf Mobilgeräten wichtig. Dazu muss Informations- und Ausbildungsmaterial für die verschiedensten Gerätemodelle erstellt werden. Abgeleitet von der heutigen Arbeitsweise sollten im Rahmen eines Projektes, das in Zusammenarbeit mit der MAGH UND BOPPERT GMBH durchgeführt wurde, Methoden und Techniken entwickelt werden, die die Produktion von Informations- und Schulungsunterlagen in Papier- und elektronischer Form beschleunigen. Erstellte Unterlagen sollten auf die verschiedenen Bedürfnisse (Customer Care, Sales² ) ausgerichtet sein. Der Mehrsprachigkeit und der Modularität der Inhalte sowie ihrer Anpassung/Abänderung sollte dabei speziell Beachtung geschenkt werden. Als Endprodukt ist ein Autorentool für die Mobilfunkgeräteausbildung geplant.

1.2. Aufgabenbeschreibung

Ein Teilbereich dieses Projekts bestand in der Evaluation verschiedener Möglichkeiten, Screenshots von Mobilgeräten zu erstellen, um sie in Lerneinheiten zu verwenden. Dies ist zurzeit ohne Weiteres nicht möglich. Bei der Vielzahl der Geräte unterschiedlichster Hersteller existiert kein herstellerunabhängiges Tool und es werden auch verschiedene Betriebssysteme verwendet. Ziel der Studienarbeit sollte es sein, eine einheitliche, möglichst weit automatisierte und schnelle Art der Anfertigung von Lerninhalten mithilfe von Screenshots aufzuzeigen und pilotartig zu präsentieren. Hierzu sollte Folgendes durchgeführt werden:

1. der Ist-Zustand bzgl. der Anfertigung von Lerninhalten bei der SM ermittelt werden

2. unterschiedliche Methoden zur Produktion von Screenshots recherchiert und anschließend auf Machbarkeit, Automatisierbarkeit und Kosten geprüft werden. Folgende Verfahren sind zu berücksichtigen:

a. Capturingtools auf den Mobilgeräten
b. Fotografieren der Bildschirmausgaben der Mobilgeräte mit Datentransfer an
den Computer
c. Gegebenenfalls andere Möglichkeiten

3. die zweckmäßigste Lösung für die SM bestimmt werden

4. Anforderungen an eine vollständige Lösung erarbeiten werden

5. eine Spezifikation eines Autoringtools erstellt werden

6. der voraussichtliche Zeitaufwand bei der Erstellung von Lerninhalten mittels des Autorentools ermittelt und dieser mit dem Verfahren verglichen werden, das heute bei der SM genutzt wird

7. ein Pilot erstellt werden, der die Möglichkeiten eines Autorentools beispielhaft aufzeigt

8. Hinweise zur Softwaretechnischen Umsetzung gegeben werden.

1.3. Arbeitsprozess

Die Studienarbeit nahm ihren Anfang damit, dass Julien B.von der MAGH UND BOPPERTGMBH an mich herantrat und mir nach der Vorstellung des Projekts mit der SM anbot, einen Teilbereich als Studienarbeit durchzuführen. Hierzu habe ich mit Jürg M., einem Verantwortlichen für die Weiterbildung bei der SM , und Marc Mü., der zu der Zeit in der Ausbildung zum Mediamatiker bei der SM war, Kontakt aufgenommen. Zusammen haben wir uns auf meinen Aufgabenbereich im Projekt verständigt.

In wöchentlichen Telefonkonferenzen und unter Zuhilfenahme von Desktopsharing-Software habe ich die Anforderungen der SM aufgenommen und den Ist-Zustand bei der SM analysiert. Hiernach habe ich das Fotografieren von Bildschirmausgaben der Mobilgeräte als Methode des Screencapturings untersucht und weitere Möglichkeiten recherchiert. Als Nächstes habe ich ausgehend von den heutigen Schulungsunterlagen der SM eine Lernsoftware entworfen. Im Vordergrund stand hier nicht die Erstellung eines vollständigen Entwurfsdokuments, sondern die Gestaltung der Benutzungsschnittstelle unter Beachtung aller geforderten Anforderungen und der Integration meiner Ergebnisse aus der Machbarkeitsstudie zum Screencapturing. Unter Beisitz von Prof. Magenheim habe ich das Konzept bei einer Videokonferenz mit der Schweiz allen Projektbeteiligten vorgestellt.

Meine Aufgabenbeschreibung hat sich nach der Präsentation noch geändert. Jürg M. hatte noch weitere Anforderungen an die Software und es wurde klar, dass die Programmierung eines funktionierenden Piloten, bei dem Umfang der Software, von mir im Rahmen einer Studienarbeit nicht zu schaffen wäre. Durch die Präsentation wurde das durch Julien B.auch nicht mehr für nötig empfunden, weil die Funktionsweise und das Look & Feel deutlich vermittelt werden konnten. Ich habe trotzdem einen sehr rudimentären klickbaren Piloten in html erstellt, der den Prozess der Erstellung einer Lerneinheit illustrieren soll.

Anschließend habe ich noch Mobilgeräte von der SM gestellt bekommen, die ich zum Testen von Screencapturingtools verwendet habe. Meine Entscheidung, das Fotografieren als Capturingmethode in die Software zu integrieren, haben die Tests aber nicht verändert, sondern noch weiter verstärkt.

Zum Schluss habe ich die Gestaltung der Benutzeroberfläche noch ein wenig verändert und die zwischenzeitlichen Anforderungen der SM umgesetzt.

1.4. Aufbau der Arbeit

Die Studienarbeit beginnt mit Tests und Machbarkeitsstudien von Methoden zum Screencapturing (Kapitel 2). Diese umfassen vorhandene Screencapturingtools, die Fotografie von Mobilgeräten und zwei weitere Verfahren. Aus den einzelnen Ergebnissen wird ein Vergleich gezogen und eine Entscheidung für ein Verfahren gefällt, das in ein Autorentool integriert werden soll.

Im 3. Kapitel ist die Anforderungsanalyse aufgeführt. Diese beinhaltet die Analyse des Ist- Zustandes, die Anforderungen der SM und meine eigenen Anforderungen an das Autoringtool.

Resultierend aus den bisherigen Ergebnissen wird in Kapitel 4 das Grundkonzept der Software erläutert. Basierend auf den Anforderungen schließt sich die Vorstellung des Designs der Software an. Hier wird die Benutzungsschnittstelle unter pädagogischen und softwareergonomischen Gesichtspunkten präsentiert.

Im weiteren Verlauf wird die Spezifikation des Autorentools (Kapitel 7.1) anhand von Geschäftsprozessen und Use Cases beschrieben, gefolgt von Hinweisen zur hard- und softwaretechnischer Umsetzung im 7.1.Kapitel.

Nach einem Aufwandsvergleich zwischen der heutigen Erstellung von Lernmaterial bei der SM und der geschätzten Erstellungszeit mit dem Autorentool, werden noch weitere Konzepte zur Gestaltung von Lernumgebungen aufgeführt. Die Arbeit endet mit einem Resümee.

Auf der beigefügten CD befindet sich eine große Auswahl der geschossenen Fotos und Screenshots, die Präsentationsfolien für die erwähnte Videokonferenz, der rudimentäre Pilot und natürlich die Studienarbeit in digitaler Form.

2. Capturingmethoden

2.1. Kapitelübersicht

Eine Teilaufgabe der Studienarbeit war, unterschiedliche Methoden zur Produktion von Screenshots auf Machbarkeit, Automatisierbarkeit und Kosten zu prüfen. In diesem Kapitel werden zuerst vorhandene Screencapturingtools, anschließend das Fotografieren der Mobilgeräte und zuletzt zwei weitere mögliche Methoden vorgestellt. Im letzten Unterkapitel werden die einzelnen Verfahren bewertet und miteinander auf Machbarkeit und Realisierbarkeit im Hinblick der Verwendung innerhalb eines Autorentools verglichen.

2.2. Screencapturingtools

Auf dem Markt sind eine Vielzahl von Screencapturingtools für mobile Endgeräte zu finden, eine Teilmenge davon zu testen und auf Stärken und Schwächen zu untersuchen, war ein Ziel dieser Arbeit. Zu diesem Zweck hat die SM freundlicherweise zwei Geräte zur Verfügung gestellt.

2.2.1. Testfeld und Testverfahren

Obwohl versucht wurde, während der Tests systematisch vorzugehen, sind diese nicht als standardisierte wissenschaftliche Experimente zu sehen und erheben auch nicht den Anspruch, Kriterien wie Reliabilität, Objektivität und Validität vollständig zu erfüllen. Vielmehr sollte ein möglichst breites Feld von Tools, bei Berücksichtigung folgender Fragen, unbefangen geprüft werden:

- Welche Systemvoraussetzungen stellt die Software?
- Wie werden die Tools installiert?
- Gibt es Besonderheiten bei der Bedienung?
- Gibt es Besonderheiten bei den Programmeinstellungen?
- Wie zeitaufwändig ist das Capturing von der Installation bis zur fertigen Bildsequenz?
- Ist das Tool fehlerfrei oder kommt es zu unerwünschtem Verhalten?

Um Mängel bei den Tools festzustellen, wurden möglichst viele Eventualitäten beim Screencapturing berücksichtigt. Das Problem mit nicht aufgenommenen Menüs war schon im Vorfeld von der SM (Kapitel 3.3) bekannt, andere sind erst beim Testen der einzelnen Programme aufgetreten. Diese wurden dann in die Prüfkriterien mit aufgenommen und bei den übrigen Tools ebenso getestet. Wenn es technisch durchführbar war, wurden dazu unter folgenden Kriterien Screenshots gemacht:

- mit offenen Menüleisten und Kontextmenüs
- bei Videowiedergabe
- von offenen Programmen
- von Ladebalken und Startfenstern von Programmen
- während der Videoaufnahme und Fotografie mit dem Mobilgerät
- von Texten mit kleiner Schrift
- von Bildern mit hohem Detailgrad
- bei Eingehenden Anrufen auf dem Gerät
- querformatiger Bildschirmausgabe

Die Checklisten mit detaillierten Ergebnissen sind im Anhang³nachzulesen.

Getestet wurde auf zwei Mobilfunkgeräten, einem Nokia 6680 mit dem Betriebssystem Symbian OS v8.0 und einem XPA S 200 mit Windows Mobile 5.0. Auf dem Desktop war Windows XP Professional mit Service Pack 2 installiert. Insgesamt wurden siebzehn Programme bemüht, sieben für Symbian (Tabelle 2-1) und zehn für Windows-Plattformen (Tabelle 2-2 und Tabelle 2-3), die alle als Demo-, Shareware- oder Freewareversionen frei erhältlich waren. In den Tabellen sind neben dem Softwaretitel und der getesteten Version auch Hinweise zur Installation und eine Zusammenfassung der Besonderheiten der Tools und der aufgetretenen Probleme während der Tests übersichtlich dargestellt.

2.2.2. Testergebnisse

Zu den Capturingtools für Windows Mobile ist generell Nachstehendes zu sagen. Bis auf SuperSnap, das als ausführbare Datei direkt auf dem Mobilgerät installiert wird, setzen alle eine bestehende Datenverbindung zum Windows-PC mit eingerichtetem ActiveSync voraus. Die Software muss also vom PC aus über ActiveSync auf dem Gerät installiert werden. Drei der Tools (PocketSnap, RhinoCapture, HauteCapture) konnten nicht getestet werden, weil die Installationsroutine fehlschlug oder ein Starten des Programms nicht möglich war. Über ScreenPic von Scepter Corporation kann keine Aussage gemacht werden, da die Trial- Version nur das Schießen eines einzigen Bildes pro Installation erlaubte und hier ein Testen enorm zeitaufwändig geworden wäre.

Auch bei den anderen Tools hat es Probleme und zu beanstandende Punkte gegeben. Pocket Snapshot zum Beispiel hat mehrfach das Desktop-Betriebssystem eingefroren und auch die Einrichtung war nicht trivial, da die Verbindung zwischen PC und mobilem Endgerät über TCP/IP vorgenommen wird.

Bei Pocket Snapshot 3.0 fror die Remote-Control ein, wenn eine Telefonverbindung aufgebaut wurde. Dieser Fehler konnte immer reproduziert werden. Zum anderen war hier die Auslöseverzögerung mit knapp zwei Sekunden so lang, dass es schwer war, Bildschirminhalte aufzunehmen, die nur kurz erscheinen, wie Startfenster oder Ladebalken. Pocket Controller Professional, ScreeenCapture und Pocket Snapshot 3.0 bauen eine Remote-Verbindung vom PC zum Mobilgerät auf, so dass dieses über den PC ferngesteuert werden kann, ebenso wird die Bildauslösung vom PC aus vorgenommen. Dieses grundsätzlich komfortable Bedienkonzept erwies sich in der Praxis aber oft als fehlerhaft. Manches Mal hatte die Kopie des Bildschirminhaltes des XPA auf dem Gerät so viele Bildartefakte, dass eine Fernsteuerung nicht mehr akkurat erfolgen konnte. Bei Querformaten wurden die Mausbefehle an ganz andere Bildschirmstellen gemapped, als es auf dem PC zu sehen war.

Bei drei Tools kam es zu fehlerhaften Aufnahmen, entweder weil das Kontextmenü nicht mit aufgenommen wurde (ScreenShotCE) oder weil Bildschirminhalte bei Querformat abgeschnitten wurden (Abbildung 2-2 und Abbildung 2-3).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1: Tabelle mit verwendeten Screencapturingtools für das Nokia6680 mit der Zusammenfassung von Besonderheiten und Problemen bei der Benutzung

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-2: Erste Tabelle mit verwendeten Screencapturingtools für das XPAS 200 mit der Zusammenfassung von Besonderheiten und Problemen bei der Benutzung

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-3: Zweite Tabelle mit verwendeten Screencapturingtools für das XPAS 200 mit der Zusammenfassung von Besonderheiten und Problemen bei der Benutzung

Die Capturingtools für Symbian werden alle direkt auf dem Nokia installiert. Das bedeutet, dass die .sis-Dateien erst in den Speicher des Gerätes transferiert werden müssen und dann auf dem Gerät gestartet werden. Auch hier konnten nicht alle Programme gestartet bzw. installiert werden und die Bilder von YewSnap waren völlig unbrauchbar (Abbildung 2-5). Bei Psiloc Screencapture (Abbildung 2-6) erscheint nach dem Auslösen ein Dialog für die Dateinameneingabe des gemachten Bildes, wenn allerdings die Auslösetaste länger gedruckt wurde, ist fälschlicherweise der Dialog mit aufgenommen worden.

Abbildung in dieser Leseprobe nicht enthalten

2.2.3. Fazit

Schlussfolgernd ist zu sagen, dass bis auf wenige Ausnahmen die meisten hier vorgestellten Tools zum Screencapturing unausgereift sind und vielfach auch völlig unbrauchbar. Alle Tools haben gemeinsam, dass sie eine Installation erfordern, die natürlich mit einem mehrminütigen Zeitaufwand verbunden ist. Bei den Programmen für Windows Mobile ist sogar zusätzlich noch eine Installation einer aktuellen ActiveSync-Version erforderlich. Bei Pocket Snapshot zum Beispiel muss der Benutzer auch grundlegende Netzwerkkenntnisse mitbringen, die von einem Angestellten im Weiterbildungsbereich (Kapitel 1) sicherlich nicht vorausgesetzt werden können. Auch ist die Bedienung der Tools nicht gleich und es müssen die Auslösetasten für das Capturing festgelegt werden, d. h. dass für die Einstellung der Tools Zeit eingeplant werden muss. Jedoch existiert sicherlich auch gute und ausgereifte Software auf diesem Gebiet wie ScreenCapture von Vito Technology.

2.2.4. Möglichkeiten der Integration in ein Autorentool

Doch wie könnte die Integration der Tools in den Erstellungsprozess von Lerneinheiten mittels eines Autorentools aussehen? Die einfachste aber sicherlich auch schlechteste Lösung wäre, weiterhin die unterschiedlichen Capturingtools gesondert zu benutzen und anschließend die gemachten Bilder mit dem Autoringtool zu Lerneinheiten zusammenzuführen. Damit würden aber alle Probleme der Tools in den Erstellungsablauf einfließen und in dieser Phase könnten keine Prozessverbesserungen stattfinden.

Eine andere Herangehensweise wäre, für jedes Betriebssystem ein gutes fehlerfreies Screencapturingtool zu suchen und dieses an das Autorentool zu knüpfen. Hier fallen alle Tools, die direkt auf dem Mobilgerät installiert werden, von vornherein heraus, nur solche die über eine aktive Datenverbindung zum Mobilgerät vom PC aus gesteuert werden, könnten in Betracht kommen. Auf Windows Mobile stehen hier einige Programme zur Auswahl, für Symbian bot keines der getesteten Tools eine solche Bedienung. Die Anforderungen (Kapitel 3.3) an das Autorentool besagen jedoch, dass alle heutigen und zukünftigen Betriebssystemversionen von Symbian, Windows Mobile und Palm OS unterstützt werden sollen (Kapitel 3.3). Zusätzlich zu den genannten existieren auch andere Betriebssysteme für Mobilgeräte wie PEN/GEOS, Blackberry oder Linux-Distributionen wie OPIE oder MAEMO.

Demnach besteht das Problem entsprechende Software, die tadellos funktioniert und eine API mitbringt, für jedes Mobilgeräte-Betriebssystem zu finden und diese anschließend in ein Autorentool zu integrieren; der Entwicklungsaufwand wäre hier enorm. Würde eine solche Software produziert, wäre damit die Entwicklungsarbeit aber noch lange nicht getan. Der Mobilgerätemarkt ist noch relativ jung und unterliegt ständigen Neu- und Weiterentwicklungen, so dass die Software an neue Capturingtools für neue Betriebssystemversionen oder völlig neue Betriebssysteme adaptiert werden müsste. Die Entwicklung von Microsoft Windows CE bis zu Windows Mobile, die Psion-eigenen Betriebssysteme namens SIBO und EPOC, das sich letztlich in Symbian auflöste, oder nicht mehr weiter verfolgte Systeme wie Newton OS oder das von Casio entwickelte PVOS (Pocket Viewer Operating System) illustrieren die in diesem Marktsegment existierende Fluktuation an konkurrierenden Plattformen.

2.3. Digitalfotografie

Auf der Suche nach neuen Möglichkeiten Screenshots von mobilen Endgeräten zur Produktion von Lerneinheiten anzufertigen, sollte das Fotografieren der Bildschirmausgabe als eine Technik des Capturings auf Praxistauglichkeit untersucht werden. Dies schließt eine Beurteilung ein, ob dieses Verfahren die gestellten Anforderung aus Kapitel 3 an Screenshots erfüllt, welche Voraussetzungen damit verbunden sind und welche Kosten und welcher Zeitaufwand aus dieser Art des Capturings resultieren.

Bei dem Erstellen der Screenshots kamen drei unterschiedliche Kameramodelle zum Einsatz, die sich hinsichtlich ihrer Funktionalität und Qualität teils deutlich unterschieden haben. Einmal die Canon EOS 350D Digital mit 8Megapixel und einem Tamron Super-Zoom- Objektiv. Dies ist eine Spiegelreflexkamera, die sich an Einsteiger und Hobbyfotografen richtet und sich zum Zeitpunkt des Tests im Preissegment von 500-700 € befand (ohne Objektiv). Die zweite war eine Kodak Easyshare P880, ebenfalls mit 8 Megapixeln und einem Schneider-KREUZNACH-Festobjektiv mit einer Brennweite von 24-140mm, die sich im Bereich von 400-500 € bewegte. Als Stativ kam ein Dreibein zur Verwendung. Mit dieser Fotoausrüstung wurden folgende sechs Handy- bzw. PDA- Modelle fotografiert:

- Siemens Xelibri 2 mit Monochrom-Display (Displaygröße von 29 x 19 mm, 2 Farben, Auflösung von 101 x 64 Pixel)
- Siemens CF 110 mit Farb-Display (Displaygröße von 32 x 32 mm, 65.536 Farben, Auflösung von 130 x 130 Pixel)
- Siemens CX 75 mit Farb-Display (Displaygröße von 30 x 37 mm, 262.000 Farben, Auflösung von 132 x 176 Pixel)
- Nokia 3410 mit Monochrom-Display (Displaygröße von 32 x 24 mm, 2 Farben, Auflösung von 96 x 65 Pixel)
- Nokia 6680 mit Farb-Display (Displaygröße von 35 x 41 mm, 262.144 Farben, Auflösung von 176 x 208 Pixel)
- Qtek XPA S 200 mit Farb-Display (Displaygröße von 2.8", 65.536 Farben, Auflösung von 240 x 320 Pixel)

Bei den Tests wurde die jeweilige Kamera an dem Stativ befestigt und der Schwenkarm vertikal um 90° gekippt, so dass die Kameralinse auf den Boden zeigt. Das Mobilgerät befand sich unter der Kamera und wurde so ausgerichtet, dass die Displaykanten des Mobilgerätes möglichst parallel zu den Bildkanten in dem Sucher der Kamera standen, anschließend wurde alles fixiert. Hierbei wurde mit unterschiedlichen Kameraeinstellungen wie Auflösung, Zoom, Kompression, Belichtungsdauer, Blende, Fokussierung oder Belichtung experimentiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-7: Bildausschnittsvergrößerung eines Fotos; geschossen mit Canon 350D Digital vom Siemens CX75

Die beiden erstgenannten Fotoapparate hatten beide eine sehr gute Bildqualität, zum einen aufgrund der hohen Pixelzahl, zum anderen durch die qualitativ hochwertigen Objektive, die relativ wirklichkeitsgetreue Aufnahmen erlauben. Während der Tests konnten keine erkennbaren Qualitätsunterschiede zwischen den Aufnahmen beider Geräte ausgemacht werden. Bei voller Auflösung konnten in jedem Screenshot die einzelnen Pixel der Displays der mobilen Endgeräte erkannt werden (Abbildung 2-7). Dies bedeutet, dass bei diesen Modellen keine Informationsverluste entstehen und eine 1:1 Kopie des Bildschirminhalts des Mobilgeräts möglich ist.

Die Fotografie zum Erstellen von Screenshots zu nutzen, hat einige wesentliche Vorteile gegenüber den Screencapturingtools. Das Verfahren ist nicht abhängig vom Betriebssystem des Mobilgerätes und stellt an diese auch sonst keine Anforderungen und Restriktionen hinsichtlich Soft- oder Hardware. Hiermit ist verbunden, dass auch kein

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8: Siemens Xelibri 2 fotografiert mit Kodak P880 und eingeschaltetem Blitz

Installationsaufwand auf dem Handy/PDA/Smartphone entsteht. Weiterhin wird immer exakt der dargestellte Bildschirminhalt aufgenommen, fehlerhaftes Capturing durch fehlende Menüs oder abgeschnittene Displaybereiche sind hier ausgeschlossen. Auch entstehen nur einmalige Anschaffungskosten für die Fotoausrüstung, wogegen bei den Capturingtools mindestens ein Produkt je Betriebssystem kalkuliert werden muss.

Die Anforderungen aus Kapitel 3 können mit diesem Verfahren erfüllt werden, so dass es als Alternative zu Screencapturingtools in Frage kommt. Wie immer bei der Fotografie sind allerdings einige Regeln bei der verwendeten Technik, den Kameraeinstellungen und der Beleuchtung zu beachten. So ist z. B. von der Benutzung eines Blitzes abzuraten (Abbildung 2-8). Auch sind der Fotografie physikalische Grenzen gesetzt, die nicht umgangen werden können und sich nachteilig auf die Qualität der Screenshots auswirken können. So werden im Gegensatz zu Screencapturingtools Verschmutzungen, Kratzer und Displayfehler auch auf der Aufnahme zu sehen sein (Abbildung 2-9).

Ein weiterer Nachteil sind die Anschaffungskosten für die Fotoausrüstung die mit mindestens ca. 1300 € zu Buche schlagen, nach oben hin sind keine Grenzen gesetzt. Die Ausrüstung muss selbstverständlich auch aufgebaut und

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9: Uhrzeitanzeige auf dem Siemens CX⁷⁵, fotografiert mit Canon EOS³⁵⁰D Digital

justiert werden, was jedoch nur erstmalig passieren muss. In Kapitel 7.1 sind alle Erfahrungen und daraus resultierende Empfehlungen ausführlich aufgeführt. Eine Auswahl der gemachten Fotos kann im Anhang B betrachtet werden, alle Fotografien sind auf der beigelegten CD zu finden.

Besonders erwähnenswert ist noch eine Funktionalität der Spiegelreflexkamera von Canon. Die EOS 350D kann während des Betriebs an den PC angeschlossen und als Wechsellaufwerk eingebunden werden, so dass die gemachten Bilder unmittelbar nach der Aufnahme am PC bearbeitet werden können. Dies hätte gegenüber den anderen Kameramodellen einen entscheidenden Einfluss auf die Arbeitsweise während der Erstellung von Lerneinheiten. Die Screenshots müssten nicht mehr umständlich via Speicherkarte auf den Computer transferiert werden und der Autor wäre nicht gezwungen, gleich eine ganze Bildsequenz zu schießen, um den Transferaufwand zu minimieren.

2.4. Weitere Capturingalternativen

Zwei weitere Methoden des Capturings werden in diesem Unterkapitel erklärt. Diese Methoden sind als Alternativen in betracht gezogen worden. Sie waren nicht integraler Bestandteil der Arbeit und werden deshalb nicht so ausführlich wie die letzten zwei betrachtet.

Beim proprietären Capturing bestand die Arbeit aus Recherche und theoretischen Überlegungen. Emulatoren kamen bei der SM auch schon zum Einsatz. Leider konnten keine Exemplare zur Verfügung gestellt werden, so dass dieses Verfahren auch eher theoretisch mit den durch Recherche ermittelten Informationen betrachtet wird.

2.4.1. Proprietäres Capturing

Ein weiteres alternatives Capturingverfahren wäre die Programmierung eines proprietären Screencapturingtools, das vielleicht sogar als Teil eines Autorentools implementiert würde. Die Vorteile einer solchen Lösung liegen auf der Hand. Die Benutzungsschnittstelle wäre immer gleich, umständliche Softwareinstallationen könnten vielleicht entfallen, die Qualität der Screenshots wäre gleich bleibend und die Screenshots könnten übergangslos in die Lerneinheiten integriert werden. Eine einheitliche Screencapturing-Lösung, für alle oder wenigstens die wichtigsten Betriebssysteme, konnte nicht gefunden werden und eine Entwicklung in dieser Richtung wäre verständlicherweise extrem aufwändig und kostspielig und würde für eine so spezielle Anwendung, wie das zu entwickelnde Autorentool, sicherlich den Preisrahmen sprengen. Nachträgliche Integrationen von neuen Betriebssystemen müssten auch berücksichtigt werden.

Eine praktikable Lösung wäre eine plattformunabhängige Implementierung in Java ME (Java Micro Edition)⁴. Diese ist eine auf Kleinstkonfigurationen ausgelegte Java Edition, die bereits von vielen Mobilgeräteherstellern lizenziert wurde⁵ und von fast allen aktuellen Geräten neuen unterstützt wird⁶. Von älteren Geräten könnte so aber kein Capturing gemacht werden, das Siemens Xelibri 2 zum Beispiel bietet keine Java ME-Unterstützung. Die Konfiguration für Kleingeräte wird Connected Limited Device Profile (CLDC) genannt, die Java ME API ist aber im Vergleich zur Standard Edition stark beschnitten und so besteht hier nach derzeitigem Kenntnisstand keine Möglichkeit Screencapturing zu realisieren. In J2SE existieren mehrere Wege die Bildschirmausgabe auszulesen, die ImageRecorder-⁷, die JPEGImageRecorder-⁸ und die AWT.Robot-Klasse⁹. Diese sind aber nicht Bestandteil der Java ME API, weshalb auch nach längerer Recherche keine Möglichkeit gefunden wurde, ein Screencapturingtool in Java ME zu implementieren. Das wird auch dadurch gestützt, dass keine Software zum Screencapturing auf mobilen Endgeräten ausfindig gemacht werden konnte, die in Java geschrieben wurde. Eine Recherche nach anderen plattformunabhängigen Programmiersprachen für Mobilgeräte führte ebenfalls zu keinem Ergebnis.

2.4.2. Emulatoren

Eine Emulation der Mobilgerät-Betriebssysteme auf dem PC wäre eine Option, um ein Capturing direkt auf dem Computer zu bewerkstelligen. Hierzu wurden der Palm OS Emulator POSE¹⁰, der Windows Mobile 5.0 Emulator für Smartphones¹¹ und der Windows Mobile 5.0 Pocket PC Emulator¹² ausprobiert.

Das große Plus einer Emulation ist natürlich, dass das eigentliche Mobilgerät nicht mehr benötigt wird und ein qualitativ hochwertiges Capturing der PC-Oberfläche leicht in ein Autorentool integriert werden könnte.

Das riesige Minus sind aber die technischen Voraussetzungen und das teilweise erforderliche informatische Know-how. Die Installation von POSE ist noch sehr simpel, da nur eine ausführbare Datei geöffnet werden muss. Der Windows Mobile 5.0 Emulator for Smartphone allerdings benötigt eine Installation von Visual Studio 2005 und Windows Mobile Smartphone SDK. Dies setzt hohe Anschaffungskosten voraus und bedeutet im Folgeschluss, dass die Emulation in einer Entwicklungsumgebung abläuft und ein Autor über fundierte Kenntnisse der Softwareprogrammierung verfügen sollte. Dies kann von einer Person mit pädagogischer Ausbildung nicht erwartet werden (Kapitel 3.2, Zielgruppe). Ein weiterer Nachteil ist, dass an Corporate Designs angepasste Betriebssystemversionen für Mobilgeräte hiermit nicht ohne Weiteres emuliert werden könnten, dies war bei dem in Kapitel 2.2 verwendeten Nokia 6680 der Fall. Hier müssten weitere Anpassungen vorgenommen werden, eine technische Realisierbarkeit vorausgesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-10: Screenshot des Palm OS Emulators POSE

Das größte Manko ist aber, wie auch schon bei den Screencapturingtools, die erforderlichen Emulatoren für jedes Betriebssystem bereitzustellen. Eine Integration einer Vielzahl von Emulatoren in ein Autorentool wäre wahrscheinlich noch weitaus aufwendiger, als die vorhandener Screencapturingtools zu nutzen.

2.5. Bewertung der Screencapturingmethoden

Werden die Verfahren der letzten Kapitel hinsichtlich ihrer Realisierbarkeit in einem Autorentool miteinander verglichen, muss dem Capturing mittels Fotografie der Vorzug gegeben werden. Der Grund dafür ist nicht, dass eine Methode a priori nicht die geforderten Anforderungen an ein Screencapturing (Anforderungen in Kapitel 3) erfüllt. Eine Emulation, die Integration bestehender Screencapturingtools und die Entwicklung eines proprietären Screencapturings scheitern aber an den großen technischen Hürden bzw. den hohen Anforderungen an das Know-how des Benutzers. Plattformunabhängige Implementierungen wären enorm kosten- und zeitaufwändig und würden mit jedem neuen MobilgeräteBetriebssystem weiteren Implementierungsaufwand mit sich führen, eine solche Softwarelösung würde niemals eine endgültige Version erreichen.

Hingegen ist die Kameratechnik bereits vorhanden und vollkommen plattformunabhängig. Wie oben erwähnt, existieren Digitalkameras mit sofortiger Synchronisation der Bilder an den PC, der einzige Implementierungssaufwand bestünde darin, die Bilder nach der Synchronisation automatisch in ein Autorentool übertragen zu lassen. Verglichen mit den anderen Methoden ist dies sicherlich die eleganteste und kostengünstigste Lösung. Lediglich eine plattformunabhängige Programmiersprache wäre eine echte Alternative, um ein proprietäres Capturingtool zu implementieren. Durch die Limitierungen von Java ME wird aber zurzeit keine Möglichkeit einer praktikablen Lösung auf diesem Wege gesehen. Resultierend aus den genannten Pro und Kontras der betrachteten Lösungsalternativen wird das in den nächsten Kapiteln vorgestellte Autorentool die Digitalfotografie zum Capturing integrieren.

3. Anforderungsanalyse

In diesem Kapitel sind alle Anforderungen an ein Autorentool und die integrierte Capturingmethode definiert. Diese entstanden teils durch Interviews und Gespräche mit Jürg M. und Marc Mü., teils durch Vorgaben der SM und teils auch durch eigene Überlegungen und Zielsetzungen. Die Anforderungen der SM waren eher technischer Art, meine eigenen eher didaktischer Natur.

3.1. Ist-Zustand

Grundlage für das Design eines Autorentools waren Schulungsmaterialien für Mobilfunkgeräte, wie sie derzeit bei der SM erstellt und verwendet werden. Eine Beispielschulungsunterlage der SM , bei der Screenshots zum Einsatz kommen, ist in Abbildung 3-1¹³ zu sehen. Sie soll die Inbetriebnahme von Smart Office auf einem Palm Trèo 650 anhand der Einzelschritte, die auf dem Palm durchgeführt werden müssen, beschreiben. Die Lerneinheiten werden folgendermaßen erstellt: Zuerst wird ein passendes Screencapturingtool auf dem Gerät installiert, was ggf. noch gefunden und aus dem Internet geladen werden muss. Danach werden die einzelnen Screenshots auf dem mobilen Endgerät erstellt und später auf den PC kopiert. Dies geschieht je nach Gerät mittels Speicherkarte oder kabelgebundener bzw. kabelloser Datenübertragung. Die Bilder werden in MS Publisher importiert, in der Größe angepasst und in ein Raster gestellt. Zuletzt werden die schriftlichen Kommentare und Anweisungen geschrieben und die Hand-Symbole eingeflochten. Unter Umständen ist es nötig die Bilder zu bearbeiten, entweder weil die Screencapturingtools keine 1:1-Kopie machen oder weil persönliche Daten aus den Bildern entfernt oder durch Musterdaten ersetzt werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: Ausschnitt einer Beispielanleitung der SM zur Inbetriebnahme von Smart Office auf einem Palm Trèo 650. Erweitert mit Hinweismarkierungen

[...]

---

¹ Name vom Autor geändert

² Customer Care (CuC) ist der Kundenservice der SM. Sales sind die Geschäftsfilialen der SM, die für den Verkauf von Produkten zuständig sind.

³ Siehe Tabelle C-3: Checkliste mit Testergebnissen der Screencapturingtools für das Nokia 6680 und Tabelle C-4: Checkliste mit Testergebnissen der Screencapturingtools für das QTEK XPAS 200

⁴ Siehe http://java.sun.com/javame/technology/index.jsp

⁵ Siehe http://java.sun.com/javame/licensees/index.jsp

⁶ Siehe http://developers.sun.com/techtopics/mobility/device/pub/device/list.do

⁷ Siehe http://java.sun.com/products/java-media/jai/forDevelopers/jai- apidocs/com/sun/media/jai/codec/ImageEncoder.html

⁸ Siehe http://java.sun.com/j2se/1.3/docs/guide/2d/api-jpeg/com/sun/image/codec/jpeg/JPEGImageEncoder.html

⁹ Siehe http://java.sun.com/j2se/1.3/docs/api/java/awt/Robot.html

¹⁰ Palm OS Emulator POSE mit Palm OS 4.0. Bezugsquelle: http://www.pdaforum.de/emulator/

¹¹ Localized Windows Mobile 5.0 Smartphone Emulator Images - Deutsch. Bezugsquelle: http://www.microsoft.com/downloads/details.aspx?FamilyID=52fed581-8f8d-4c46-9966- 4832098191b7&DisplayLang=de

¹² Localized Windows Mobile 5.0 Pocket PC Emulator Images. Bezugsquelle: http://www.microsoft.com/downloads/details.aspx?familyid=eec33ae3-c129-4c25-abaa- 18e8e842178f&displaylang=en

¹³ Das Beispiel ist mit Hinweismarkierungen versehen und ist nur ein Teil der gesamten Anleitung. Die vollständige Anleitung ist im Anhang A in Abbildung A-1 und Abbildung A-2 zu finden.