|
|
Im nachstehenden Abschnitt wird der Bezug zur IoT-Vorlesung am Herman Hollerith Zentrum hergestellt. Hierbei werden Aspekte erläutert, die im Rahmen der Konzeption und Umsetzung der Anwendung zum Thema Reactive Room für die Vorlesungsräume am Herman Hollerith Zentrum eingesetzt worden sind.
|
|
|
|
|
|
# Reactive Room
|
|
|
Ziel des Hackathons ist es, Hybridlehrveranstaltungen durch eingebettete Services ein Stück weit in reaktive Umgebungen zu transformieren und die allgemeine Lern- und Lehrerfahrung dadurch zu verbessern. Hierzu soll nun der Begriff des Reactive Environments (z. Dt. „Reaktive Umgebung“) und des Reactive Rooms (z.Dt. „Reaktiver Raum“) definiert werden.
|
|
|
Ziel des Hackathons ist es, Hybridlehrveranstaltungen durch eingebettete Services ein Stück weit in reaktive Umgebungen zu transformieren und die allgemeine Lern- und Lehrerfahrung dadurch zu verbessern. Hierzu soll nun der Begriff des Reactive Environments (z. Dt. „Reaktive Umgebung“) und des Reactive Rooms (z.Dt. „Reaktiver Raum“) definiert werden. <br> <br>
|
|
|
|
|
|
Eine reaktive Umgebung ist eine physische Umgebung in der realen Welt, in die IoT Anwendungen eingebettet sind. Hierzu ist die Umgebung mit den notwendigen Sensoren, Reaktoren und Netzwerkkomponenten ausgestattet. Das wichtigste Kriterium einer reaktiven Umgebung ist die „Unsichtbarkeit“ der IoT Anwendungen. Die Benutzeroberfläche ist also so in der Umgebung und in sich in ihr befindenden Objekte integriert, dass sie für den Nutzer nicht sichtbar ist und die Bedienung der IoT Anwendung keine zusätzlichen Arbeitsschritte notwendig sind.
|
|
|
Eine reaktive Umgebung ist eine physische Umgebung in der realen Welt, in die IoT Anwendungen eingebettet sind. Hierzu ist die Umgebung mit den notwendigen Sensoren, Reaktoren und Netzwerkkomponenten ausgestattet. Das wichtigste Kriterium einer reaktiven Umgebung ist die „Unsichtbarkeit“ der IoT Anwendungen. Die Benutzeroberfläche ist also so in der Umgebung und in sich in ihr befindenden Objekte integriert, dass sie für den Nutzer nicht sichtbar ist und die Bedienung der IoT Anwendung keine zusätzlichen Arbeitsschritte notwendig sind. <br> <br>
|
|
|
|
|
|
Ein Reactive Room, also ein reaktiver Raum ist eine reaktive Umgebung, die sich auf einen Raum begrenzt. Da dieser Raum meist einen bestimmten Zweck erfüllt (der Zweck eines Vorlesungsraums ist das Abhalten von Lehrveranstaltungen), sind die IoT Anwendungen diesem Zweck angepasst.
|
|
|
Ein Reactive Room, also ein reaktiver Raum ist eine reaktive Umgebung, die sich auf einen Raum begrenzt. Da dieser Raum meist einen bestimmten Zweck erfüllt (der Zweck eines Vorlesungsraums ist das Abhalten von Lehrveranstaltungen), sind die IoT Anwendungen diesem Zweck angepasst. Im Vergleich zu Anwendungsfällen in der Industrie, werden in einem Reactive Room die Regeln, denen das System unterliegt, von den Menschen vorgegeben. <br> <br>
|
|
|
|
|
|
Ein bekanntes Beispiel für einen reaktiven Raum ist der Reactive Room in der Universität von Toronto im Jahre 1995. Die Forscher erkannten, dass der Raum für Videokonferenzen zwar gut mit neuen Technologien ausgestattet war, die Bedienung dieser jedoch nicht ganz einfach war. Also wurde ein System entwickelt, das die verschiedenen Medien bedienen kann und anhand der Aktivitäten der Benutzer im Raum Annahmen treffen kann, welche Aktionen ausgeführt werden sollen. (1)
|
|
|
Ein bekanntes Beispiel für einen reaktiven Raum ist der Reactive Room in der Universität von Toronto im Jahre 1995. Die Forscher erkannten, dass der Raum für Videokonferenzen zwar gut mit neuen Technologien ausgestattet war, die Bedienung dieser jedoch nicht ganz einfach war. Also wurde ein System entwickelt, das die verschiedenen Medien bedienen kann und anhand der Aktivitäten der Benutzer im Raum Annahmen treffen kann, welche Aktionen ausgeführt werden sollen. (1) <br> <br>
|
|
|
|
|
|
Der Physical Student Twin stellt einen ersten Schritt zu einem reaktiven Raum dar, weil der Dozent ohne Benutzeroberfläche und ohne zusätzlichen Aufwand mit den Studierenden, die online zugeschaltet sind, interagieren kann. Jede*r online zugeschaltete Studierende ist durch eine physische Komponente (dem Bildschirm mit Raspberry Pi) im Vorlesungsraum repräsentiert.
|
|
|
Die Anwendung, die während dem Hackathon konzipiert und umgesetzt wird, stellt einen ersten Schritt zu einem reaktiven Raum dar, weil der Dozent ohne Benutzeroberfläche und ohne zusätzlichen Aufwand mit den Studierenden, die online zugeschaltet sind, interagieren kann. Jede*r online zugeschaltete Studierende ist durch eine physische Komponente (dem Bildschirm) im Vorlesungsraum repräsentiert. <br> <br>
|
|
|
|
|
|
Für die Konzeption und Umsetzung eines reaktiven Raums sollten bestimmte Design Prinzipien eingehalten werden.
|
|
|
Für die Konzeption und Umsetzung eines reaktiven Raums müssen bestimmte Design Prinzipien eingehalten werden.
|
|
|
|
|
|
# Design Principles
|
|
|
Design Prinzipien helfen beim Entwurf eines Systems eine einheitliche Struktur vorzugeben, um die Kompatibilität der verschiedenen Komponenten sicherzustellen. Für eine reaktive Umgebung sollten die folgenden Design Prinzipien eingehalten werden.
|
|
|
|
|
|
**Unsichtbarkeit – Invisibility** <br>
|
|
|
Das Prinzip der Unsichtbarkeit sagt aus, dass keine Benutzeroberfläche für den Benutzer sichtbar ist und die Technologie im Hintergrund arbeitet. Der Benutzer muss also keine zusätzlichen Arbeitsschritte tätigen, um die Anwendung zu bedienen.<br>
|
|
|
Im Falle des Pysical Student Twins spiegelt sich dieses Design Prinzip in Form von der physischen Repräsentation der online zugeschalteten studierenden wider. Die Reaktionen und Fragen der Studierenden werden an einem physischen Ort im Klassenraum angezeigt, sodass der Dozent direkt erkennt, wenn Fragen oder Anmerkungen vorhanden sind und somit nicht immer zum Computer laufen muss, um zu schauen, ob es im Chat der online Vorlesung Fragen gibt. Für die online zugeschalteten Studierenden ist die Benutzeroberfläche im Falle des hier ausgearbeiteten Prototyps noch visibel. In weiteren Iterationen dieses Projekts, könnte man versuchen ein Videokonferenzen-Programm zu finden, das es ermöglicht, die im Programm ausgelösten Reaktionen direkt an die physische Repräsentation vor Ort weiterzuleiten. Ein weiterer Ansatz wäre, Reaktionen der Studierenden durch Bilderkennung zu erfassen und wiederzugeben. Dies würde jedoch voraussetzen, dass alle Studierenden ihre Kamera während der Vorlesung anschalten. <br>
|
|
|
**bandbreite notwendig (bei Studis), system das 25 Videos parallel verarbeiten kann muss vorhanden sein, bandbreite/ Ressourcen auf Server Seite, Datenschutz?, Nutzer muss sich nicht damit beschäftigen, auf welchem Bildschirm, Dozent muss sich nicht darum kümmern, ... , **
|
|
|
Das Prinzip der Unsichtbarkeit sagt aus, dass keine Benutzeroberfläche für den Benutzer sichtbar ist und die Technologie im Hintergrund arbeitet. Der Benutzer muss also keine zusätzlichen Arbeitsschritte tätigen, um die Anwendung zu bedienen. <br>
|
|
|
Im Falle des Physical Student Twins spiegelt sich dieses Design Prinzip in Form von der physischen Repräsentation der online zugeschalteten studierenden wider. Die Reaktionen und Fragen der Studierenden werden an einem physischen Ort im Klassenraum angezeigt, sodass der Dozent direkt erkennt, wenn Fragen oder Anmerkungen vorhanden sind und somit nicht immer zum Computer laufen muss, um zu schauen, ob es im Chat der online Vorlesung Fragen gibt. Für die online zugeschalteten Studierenden ist die Benutzeroberfläche im Falle des hier ausgearbeiteten Prototyps noch visibel. <br>
|
|
|
Ein weiterer Aspekt der Unsichtbarkeit ist, dass sich der/die Studierende nicht damit auseinandersetzen muss, auf welchem Bildschirm er/sie sich verbindet, da er automatisch zugeteilt wird. Auch der/die Donzent*in muss sich nicht um die Zuteilung der Bildschirme kümmern. Der Dozent muss lediglich die Bildschirme vor Vorlesungsbeginn einschalten. <br>
|
|
|
In weiteren Iterationen dieses Projekts, könnte man versuchen ein Videokonferenzen-Programm zu finden, das es ermöglicht, die im Programm ausgelösten Reaktionen direkt an die physische Repräsentation vor Ort weiterzuleiten. Ein weiterer Ansatz wäre, Reaktionen der Studierenden durch Bilderkennung zu erfassen und wiederzugeben. Dies würde jedoch voraussetzen, dass alle Studierenden ihre Kamera während der Vorlesung anschalten und dass Studierende ausreichend Bandbreite zur Verfügung haben, um ein erkennbares Bild zu Streamen. Darüber hinaus bräuchte die Hochschule für die Umsetzung dieser Erweiterung ein System, das 25 Videos parallel verarbeiten kann, und einen Server, der über ausreichend Ressourcen verfügt, um die Videos zu streamen und zu verarbeiten. Darüber hinaus stellt sich die Frage des Datenschutzes, da die Videos und Gesichter der Studierenden analysiert werden würden. Dies ist ohne deren Zustimmung nicht möglich.
|
|
|
|
|
|
**Manueller Vorrang – Override** <br>
|
|
|
Der manuelle Vorrang beschreibt, dass der manuelle Eingriff durch den Nutzer automatische Einstellungen überschreibt. Ein manueller Eingriff sollte vom System als solcher erkannt werden und demensprechend priorisiert werden.<br>
|
|
|
Der Prototyp für den Digital Student Twin lässt zum aktuellen Zeitpunkt nicht viel Raum für dieses Design Prinzip. Der online zugeschaltete Studierende kann sich zwar jederzeit von der Session mit dem im Raum stehenden Bildschirm abmelden und der Dozent kann das weitere Zuschalten von Studierenden durch Ausschalten der Bildschirme verhindern, jedoch sind weitere Eingriffsmöglichkeiten im Prototyp nicht vorgesehen. Sollte der/die Studierende das Gefühl haben, dass seine Reaktionen nicht wahrgenommen werden, gibt es die Möglichkeit für einen manuellen Eingriff, indem er die Fragen und Reaktionen, wie gewohnt, über das genutzte Online-Vorlesungs-Programm versendet. <br>
|
|
|
Im Falle einer Erweiterung des Projekts durch das Ableiten der Reaktionen mit Bilderkennung, wäre es möglich dem/der Studierenden die Chance zu geben die automatisch generierte Reaktion manuell zu korrigieren. <br>
|
|
|
Für den aktuellen Stand des Prototypen... <br>
|
|
|
Der manuelle Vorrang beschreibt, dass der manuelle Eingriff durch den Nutzer automatische Einstellungen überschreibt. Ein manueller Eingriff sollte vom System als solcher erkannt werden und demensprechend priorisiert werden. <br>
|
|
|
Durch die noch vorhandene Benutzeroberfläche für die Studierenden, ist das Versenden von Reaktionen und Nachrichten nicht austomatisiert und könnte in gewisser Hinsicht als manueller Vorrang gewertet werden. Darüber hinaus lässt der Prototyp des Physical Student Twins zum aktuellen Zeitpunkt nicht viel Raum für dieses Design Prinzip. <br>
|
|
|
Der online zugeschaltete Studierende kann sich jederzeit von der Session mit dem im Raum stehenden Bildschirm abmelden und der Dozent kann das weitere Zuschalten von Studierenden durch Ausschalten der Bildschirme verhindern und die Abstände, in denen das System nach Anfragen der Studierenden sucht („Refresh Rate“) anpassen. Weitere Eingriffsmöglichkeiten sind jedoch im Prototyp nicht vorgesehen. Sollte der/die Studierende das Gefühl haben, dass seine Reaktionen nicht wahrgenommen werden, gibt es die Möglichkeit für einen manuellen Eingriff, indem er die Fragen und Reaktionen, wie gewohnt, über das genutzte Online-Vorlesungs-Programm versendet. In den nächsten Schritten könnte man die Möglichkeit für Studierende Fragen und Reaktionen zurückzuholen implementieren. <br>
|
|
|
Im Falle einer Erweiterung des Projekts durch das Ableiten der Reaktionen mit Bilderkennung, wäre es möglich dem/der Studierenden die Chance zu geben die automatisch generierte Reaktion manuell zu korrigieren.
|
|
|
|
|
|
**Rückkopplung – Feedback** <br>
|
|
|
Unter dem Prinzip der Rückkopplung versteht man die Nachvollziehbarkeit der Systemzustände. Dem Nutzer sollte es möglich sein, Systemzustände nachzuvollziehen. <br>
|
|
|
Die Benutzeroberfläche der online zugeschalteten Studierenden gibt dem Nutzer Feedback, indem gesendete Reaktionen mit einem grünen Schatten hinterlegt werden. Darüber hinaus bekommt der Nutzer eine Fehlermeldung, wenn die Nachricht nicht zugestellt werden konnte der die Verbindung abgebrochen wurde. Der Dozent erkennt den Systemzustand am Bildschirm. So lange eine Studierende oder ein Studierender mit einem der Bildschirme verbunden ist, ist sein Name auf dem Bildschirm zu sehen. Darüber hinaus ist die aktuelle Nachricht oder Reaktion der/des Studierenden auf dem Bildschirm zu sehen.
|
|
|
Die Benutzeroberfläche der online zugeschalteten Studierenden gibt dem/der Nutzer*in Feedback, indem gesendete Reaktionen mit einem grünen Schatten hinterlegt werden. Ob die Nachricht auf dem Bildschirm angekommen ist, bekommt der/die Studierende hierbei jedoch nicht vom System mitgeteilt. Ein solches Feedback könnte in weiteren Iterationen des Projekts hinzugefügt werden. Besonders wichtig wäre es zu wissen, ob die Nachricht am Bildschirm angezeigt wurde, wenn Fragen oder Kurznachrichten gesendet worden sind, da der Studierende hier auf eine Antwort wartet. Im Falle einer „emotionalen Reaktion“, also einer einfachen Reaktion durch Emojis, hat diese Art von Feedback weniger Priorität. Der aktuelle Stand des Prototyps eignet sich also derzeit vor allem für die „emotionale Reaktion“ durch Emojis. <br>
|
|
|
Der Prototyp ist noch nicht dazu in der Lage Fehlermeldungen anzugeben, wenn eine Nachricht nicht zugestellt werden konnte, oder die Verbindung zum Gerät abgebrochen wurde. <br>
|
|
|
Der Dozent erkennt den Systemzustand am Bildschirm. So lange eine Studierende oder ein Studierender mit einem der Bildschirme verbunden ist, ist sein Name auf dem Bildschirm zu sehen. Darüber hinaus ist die aktuelle Nachricht oder Reaktion der/des Studierenden auf dem Bildschirm zu sehen.
|
|
|
|
|
|
|
|
|
# IoT Kommunikation
|
... | ... | |