Ich befinde mich derzeit im dritten (nebenberuflichen) Ausbildungsjahr zum systemischen Familientherapeuten (in Deutschland) und muss -, um die Zulassung in Österreich zu bekommen - Teile des Psychotherapeutischen Propädeutikums absolvieren. Anfang war ich nicht gerade angetan von dieser Vorgabe (eine Zulassung, die in Deutschland gültig - und durch einen Dachverband zertifiziert - ist, durch eine Teil-Basisausbildung quasi für Östereich akkreditieren zu lassen).

Da ich glücklicherweise große Teile meines Studiums und der systemischen Ausbildung angerechnet bekomme, muss ich nur rund 8 Semsterwochenstunden absolvieren und habe zudem große Wahlfreiheit unter den angebotenen Veranstaltungen.

Ich habe die Gelegenheit genutzt, um einige psychotherapeutische Schulen, die ich während meines Studiums völlig ignoriert habe, näher kennenzulernen: die Freud´sche Psychoanalyse, die Integrative Therapie sowie das Psychodrama.

 
 

Zwang zur Nutzung eines bestimmten Werkzeuges oder besser Ankoppeln an vorhandene Handhabungskompetenzen?

Auf der Micreolearning-Konferenz 2006 in Innsbruck hat Prof. Kerres in einem Vortag zum Thema Potentiale von Web 2.0 nutzen" formuliert:

"Die Aufforderung, mit einem zum Beispiel in der Lernplattform inkludierten Diskussionsforum, Blog-, Chat- oder Konferenztool zu arbeiten, erscheint so als ob wir von den Studierenden fordern würden, sie müssten ihre Mitschriften auf kariertem Papier mit Bleistiften der Stärke HB mitschreiben und anschließend in Ordnern der Marke X archivieren."

Nicht nur in Bezug auf Lernplattformen, sondern auch punkto E-Portfolio-Arbeit kann ich diesem (von mir natürlich aus dem Zusammenhang gerissenen Argument) viel abgewinnen.  Ich habe mich mit dem Konzept der PLEs (Personal Learning Environments) schnell angefreundet: in von Lernenden individuell mit Web 2.0 Werkzeugen gestalteten Lernumgebungen werden Informationen aus verschiedenen Quellen mittels RSS-Technologie aggregiert. Ich weiß, die Internet-Kenntnisse der Lernenden (und Lehrenden) sind sehr heterogen, aber schließlich zeichnen sich die meisten Web 2.0 Werkzeuge dadurch aus, dass sie besonders einfach zu bedienen sind. Außerdem bedeutet die E-Portfolio-Arbeit immer gleichzeitig auch eine Aneignung von Neue Medien-Handhabungskompetenz.

Also: ich entscheide mich für die Realisierung meines E-Portfolios mit  kostenfreien Web 2.0-Angeboten. Da sich die Geschäftsmodelle der Web 2.0-Service-Anbieter schnell ändern können (aus kostenlos wird kostenpflichtig; aber natürlich ist auch die umgekehrte Richtung möglich), muss eine Grundbedingung (sozusagen ein Mindestkriterium - das der Portabilität) gelten:

Die in (m)ein E-Portfolio eingepflegten Informationen und digitalen Artefakte müssen in einem nicht proprietären, leicht handhabbaren Format jederzeit wieder auf die eigene Festplatte gesichert werden können. Sollte ein Anbieter pleite gehen oder sein Geschäftsmodell umstellen, kann ich dann jederzeit die gesicherten Daten in ein neues System transferieren.

Dieses Mindestkriterium wird übrigens von den meisten, an Bildungsinstitutionen zur Verfügung gestellten E-Portfolio-Systemen nicht erfüllt: die Mitnahme der im Laufe der Ausbildung angelegten E-Portfolios ist nicht ohne Weiteres möglich (der Export in ein SCORM-Paket erfüllt für mich nicht das Kriterium der einfachen Handhabbarkeit der gesicherten Daten).

Also: ein wichtiges Mindestkriterium habe ich erarbeitet: das der Portabilität des generierten E-Portfolios :-)

(Die eben erarbeiteten Erkenntnisse speichere ich nun auf einer Unterseite ab und verlinke damit die auf der Startseite genannte entsprechende Prämisse).

 
 

Spezialisierte E-Portfolio-Systeme?

Die Funktionalität von Open Source E-Portfolio-Systemen wie Mahara und Elgg ist beeindruckend, insbesondere auch die Möglichkeiten, digitale Artefakte (Elaborate der E-Portfolio-ArbeiterInnen in digitaler - multicodierter - Form: PDF-Dokumente, Videos, Bilder, MP3-Dateien etc.) zu versionieren, mit Metadaten zu beschreiben, zu katalogisieren etc.

Allerdings kann ich hier dasselbe Argument wie bei den CMS-Systemen geltend machen: wer soll diese Systeme hosten und pflegen?

Dieses Argument kann ich auch gleich gegen E-Learning Systeme (Lernplattformen) wie bspw. Moodle und ILIAS (die ich beide sehr schätze und extensiv in der Lehre einsetze) einbringen.

Um mir weitere Abwägungen bezüglich der Installation von kommerziellen oder Open Source Systemen auf eigenem (bzw. institutionellem) Webspace zu sparen, will ich den Fokus der Überlegungen auf die Zielgruppe der E-Portfolio-ArbeiterInnen richten: macht es überhaupt Sinn, Studierende, SchülerInnen und LehrerInnen zur Nutzung eines bestimmten Werkzeugs zu drängen (zwingen)? Diese Gedanke scheint mir wichtig genug, um damit ein neues Posting zu füllen ;-)

 
 

Content Management Systeme zur Gestaltung von E-Portfolios?

Seit einigen Jahren verwenden wir zur Pflege unserer Firmenhomepage und für weitere Web-Projekte das Open Source CMS Joomla. Auch andere Open Source CMS wie bspw. Drupal oder Typolight sind klasse und m. E. prädestiniert für die Gestaltung und Pflege von E-Portfolios. Da ich aber zukünftig die E-Portfolio-Arbeit in der Lehre einsetzen und Studierende bzw. Schulen zum Einsatz ermutigen will, konnte ich diese Systeme schon im ersten Schritt ausschließen: All diese Applikationen benötigen einen eigenen Webspace (inklusive PHP-Skriptsprache und MySQL-Datenbank), was einerseits mit Mietkosten verbunden ist und andererseits gewisse technische Kenntnisse für die Installation und Pflege (regelmäßige Updates aus Sicherheitsgründen) erfordert. Es ist m. E. auch nicht jeder Bildungseinrichtung zumutbar, einen eigenen Webserver für das Hosting von E-Portfolios der Auszubildenden zu betreiben.

 
 


Leider bietet Weebly keine Möglichkeit an, eine Art "Zurück-Button" für Unterseiten (wie bspw. diese hier) einzubauen. Unter Besinnung auf meine einmal vorhandenen Kenntnisse als Webdesigner ;-) , habe ich mittels simplem Java-Script einen Zurück-Button erzeugt:
<INPUT TYPE=BUTTON VALUE="Zurück" onClick="history.back()">
Dieser Code wird auch von älteren Browsern verstanden und benötigt keine zusätzliche Grafik. Der Text der Schaltfläche wird im Attribut VALUE zugewiesen.