ARSnova

Aus THM-Wiki
Wechseln zu: Navigation, Suche
iCampus-Projekt
Arbeitstitel ARSnova
Betreuer Quibeldey-Cirkel
Projektbeginn 2011
Mitarbeiter Christoph Thelen, Paul-Christian Volkmer, Julian Hochstetter, Jan Kammer, Daniel Knapp
Programmiersprache JavaScript, Java
Framework Dojo (seit Version 2.0), Sencha Touch (Version 1.0)


Logo 4c official v2 schlagschatten.png

ARSnova ist ein mobiles Abstimmungssystem. ARS steht für Audience Response System, sieheWikipedia. Der Zusatz „nova“ ist die Kampfansage an die alten, teuren und meist nur für Multiple-Choice-Fragen geeigneten Clicker, bekannt aus Quizshows à la Günther Jauch.

Lehrveranstaltungen haben zunehmend mehr als 100 Zuhörer/innen, Mathematik-Vorlesungen können meist nur im Audimax gehalten werden. Die didaktischen Probleme von Großveranstaltungen sind hinlänglich bekannt: fehlende Interaktion zwischen Auditorium und Lehrperson, schwierige Aktivierung der Studierenden, ängstliche Studierende melden sich nicht zu Wort. Dennoch kann aus Kapazitätsgründen nicht auf große Vorlesungen verzichtet werden.

Es gibt zwar eine Reihe von proprietären und freien ARS-Apps, man sieht ihnen aber schnell an, dass sie nicht von Dozenten aus der Lehrpraxis und für das Lehren konzipiert wurden, sondern von Entwicklern. Das didaktische Konzept und das extrem einfache Design und Handling machen ARSnova einzigartig. Nur durch Eingabe der Session-ID, also ohne Registrierung und E-Mail-Freischaltung, gelangt der Zuhörer mit einem Klick oder Tap zum Feedback-Panel. Das Erstellen einer Session und Anlegen von Fragen ist ein Kinderspiel und wird auch den unsicheren Dozenten nicht aus dem Konzept werfen.

ARSnova versteht sich als „social software“: Es gibt kein hierarchisches Benutzerkonzept. Jeder kann die App zu seinen Zwecken einsetzen, ad hoc eine Session anlegen und mit ein und derselben App alle Funktionen nutzen: als Dozent oder als Zuhörer. Eine Registrierung ist prinzipiell nicht erforderlich, es sei denn, der Dozent will die Teilnahme an Abstimmungen auf die Teilnehmer/innen seines Kurses beschränken. In diesem Fall kann er die Teilnahme an die Mitgliedschaft in einem Kurs auf einer Lernplattform (z. B. Moodle) knüpfen. Die Anonymität bei Abstimmungen und Feedback ist aber auch für angemeldete User garantiert.

Inhaltsverzeichnis

ARSnova 1.0 (Sencha Touch)

  • Idee/Entstehung
  • Entwickler + entwicklungsdauer
  • Entscheidung für sencha touch (pro contra zum damaligen zeitpunkt)
  • Unterstützte endgeräte
  • Verbreitung/Erfolg
  • Screenshots
  • Überleitung zu arsnova2 (warum stößt arsnova1 mit dem verwendeten framework an seine grenzen)

ARSnova 2.0 (Dojo)

  • Reimplementierung
  • Warum entscheidung für dojo (pro)
  • Browserkompatibilität
  • Community
  • Geschwindigkeit (nano core / amd loader)
  • Aktive entwicklung
  • Möglichkeit der nutzung von phonegap
  • Unterstützung durch IBM, Sun Microsystems, AOL
  • Neues entwicklerteam (master-absolventen + master-studierende)
  • Qa-pipeline

Backend

CouchDB

Jenkins

Git

https://scm.thm.de/arsnova

ARSnova 1.0

Version 1.0 wird nichtmehr aktiv weiterentwickelt.

git://scm.thm.de/arsnova/arsnova-legacy-js.git

ARSnova 2.0

git://scm.thm.de/arsnova/arsnova-war.git
git://scm.thm.de/arsnova/arsnova-js.git

Infrastruktur

Werkzeuge

Projektmanagement

Zieldefinition

API Dokumentation (Doxygen)

Interaktive Dokumentation der REST-API mit Springfox(Swagger)

Entwickler sollen die Möglichkeit haben eine schnelle Übersicht über die REST API des ARSnova Backends zu erhalten. Gerade für jemanden, der sich noch nicht mit der Anwendung auseinandergesetzt hat, stellt eine solche Dokumentation ein großes Zeitersparnis dar. Die Dokumentation beinhaltet die REST-URL's, akzeptierte Formate, mögliche Übergabeparameter sowie die Rückgabewerte zu den jeweiligen Befehlen.

In der Benutzeroberfläche ist es möglich die Schnittstellen in der gleichen Ansicht zu testen, indem man frei wählbare Übergabeparameter an die Schnittstelle im Value Eingabefeld einträgt und erhält anschließend eine übersichtliche Darstellung der Antwort des Servers. So kann der Entwickler ganz einfach ausprobieren, wie die REST API genau funktioniert. Ein weiterer Vorteil ist, dass er so einfach testen kann, ob die erwartete Anfrage vom Server zurückkommt und somit eventuelle Fehler in der Entwicklung auszuschließen. Umständlich Testwege über externe Tools, wie zum Beispiel Fiddler, fallen damit weg.Damit auch ein Nutzen für die internen Entwickler entsteht, soll die Schnittstellen-Dokumentation automatisch generiert werden. Zwar entsteht ein geringer Mehraufwand durch eine benötigte Dokumentation der Schnittstelle, doch im Vergleich zum Nutzen stellt diese Funktionalität einen erheblichen Gewinn dar.

Es wurde Springfox (Version 2.0), ein Swagger Framework für Spring MVC REST APIs, verwendet, welches die gewünschten Anforderungen umsetzen kann. SpringMVC erzeugt/verwaltet die REST-API und Springfox nutzt diese vorhande REST-API Struktur und generiert daraus automatisch mit dem Swagger-Framework die interaktive Dokumentation mit dem Swagger-UI. Dieses Framework wurde in das ARSnova-Backend eingebunden und die bestehenden Schnittstellen wurden entsprechend der Swagger-Spezifikationen mit Annotationen in allen Controllern und Models dokumentiert. Die entsprechende Benutzeroberfläche "Swagger UI" wurde ebenfalls in das Backend integriert, um die dokumentierten Annotationen in einem Browser darzustellen und REST-Anfragen an den Server durchzuführen.

Springfox Integration im ARSnova-Backend

Um das Springfox Framework in das Backend einzubauen, wurden folgende Dateien bearbeitet bzw neu angelegt:

[pom.xml] - Das ist eine Maven Konfigurationsdatei, in dem das Springfox Framework und andere abhängige Programmfragmente beim Buildvorgang von extern nachgeladen werden.

[src/main/java/de/thm/arsnova/config/ExtraConfig.java] - In dieser erweiterten Config-Datei wurde durch das annotieren der Konfigurationsklasse mit @EnableWebMvc ein WebApplicationContext erzeugt, also ein neuer ServletContext hinzugefügt. Um dies im Test zu simulieren, benötigen die Service-Tests die Annotation @WebConfiguration. Die Angabe der Benutzeroberflächenadresse "swagger-ui.html" ist ebenfalls hier eingetragen.

[src/main/java/de/thm/arsnova/config/SwaggerConfiguration.java] - Das ist die eigentliche Swagger Konfigurationsdatei. Mit Docket, der primären Springfox API-Config, welche mit einer "@Bean" Annotation versehen wird, kann man Ausgabe in der Swagger-Benutzeroberfäche einstellen.

[src/main/webapp/WEB-INF/spring/arsnova-servlet.xml] - Hier wurde die Swagger-Benutzeroberfläche aktiviert, die zugehörige Konfigurationsdatei inkludiert und ein Pfad für die Darstellung der Swagger UI gesetzt.

Swagger 2.0 Annotationen in Controllers und Models/Entities

In allen Controllern, in denen die Annotation "@RestController" überhalb der jeweiligen Klasse definiert wurde, ist mit folgenden Swagger Annotationen und mit passenden Werten/Beschreibungen definiert.

Beispiel Annotation in einem Controller

Verwendete Annotationen im package "de.thm.arsnova.controller":

@Api(value = "/session", description = "the Session Controller API")

@ApiParam(value = "http servlet response", required = true)

@ApiResponse(code = 201, message = "The request …")

@ApiResponses(value = {@ApiResponse(code = 404, message = "Not Found …")

@ApiOperation(value = "Get question …", nickname = "getQuestion", notes = "getQuestion(@PathVariable …)

Beispiel Annotation in einem Model/Entitie

Verwendete Annotationen im package "de.thm.arsnova.entities" und "de.thm.arsnova.entities.transport":

@ApiModel( value = "Answer" , description = "the Answer API")

@ApiModelProperty(position = 1, required = true, value = "used to display _id")

Bestimmte Controller in der Swagger UI ausblenden

In der Swagger UI werden alle Controller angezeigt, wir brauchen aber nur die RestController. Mit der "@ApiIgnore" Annotation ist es möglich bestimmte Controller aus der Swagger-Benutzeroberfläche zu entfernen. Veraltete(Deprecated) Schnittstellen werden in Swagger-UI mit einem "Warning: Deprecated" Hinweis versehen und mit der Annotation "@DeprecatedApi" und "@Deprecated" verknüpft.

Springfox-Swagger-UI

Swagger-rest-api-dokumentation.png

Die Swagger-Benutzeroberfläche ist unter folgendem Link erreichbar: http://localhost:8080/swagger-ui.html

Der Zugriff auf verschiedene API Versionen wird mit der "BASE URL" definiert!






Beispiel "Request URL" mit [BASE URL: /]

http://localhost:8080/audiencequestion/?sessionkey=123123

Beispiel "Request URL" mit [BASE URL: /v2]

http://localhost:8080/v2/audiencequestion/?sessionkey=123123


Screencast: Swagger & Springfox for ARSnova Backend API

Screencast-swagger.png

Unter folgendem Link erreichbar: https://youtu.be/pAU0Y_kTLYE









Weiterer Ausblick

Ferner könnte man die Swagger-Benutzeroberfläche an das ARSnova Design anpassen und eventuell einen eigenen Client erstellen, der wie ARSnova-Mobile mit dem ARSnova-Backend über die REST-Schnittstelle kommuniziert.

Design

Design Kritik ARSnova 1 Mobile

Login

Arsnova loginscreen.jpg
  • "Change role" Button hat nicht die entsprechende Mindesthöhe (44px)
  • Google-Login Button bildet keine Flucht mit dem Gast-Zugang Button
  • Generell ist der Abstand zwischen den Buttons nicht gleichmäßig (20 Pixel in der Vertikalen, 11 Pixel in der Horizontalen)
  • Innenabstand des Content Bereichs ist nicht gleichmäßig in der Vertikalen. Dadurch ergibt sich ein unterschiedlicher Aussenabstand des "Change role" Buttons in der Vertikalen.






Rollenauswahl

Arsnova chooserole.jpg
  • Im Vergleich mit dem Login Screen ändert sich der obere Außenabstand des ARSnova Logos ("springen" des Contents ist im Browser sichtbar)
    • In folge dessen passt der Außenabstand des kompletten Content Bereichs nicht. Oberhalb des ARSnova Logos viel Freiraum, das THM Logo "klebt" an der Tab Bar.
  • Außenabstand oberhalb und unterhalb des "Choose your role:" Labels ist ungleichmäßig; verursacht Unruhe
  • "ARSnova@YouTube" Button hat nicht die Mindesthöhe von 44px
    • Sollte generell unter "Info" zu finden sein






Session betreten

Arsnova entersessionid.jpg
Arsnova entersessionid green.jpg
  • "Logout" Button:
    • Ist das Wurzelelement der Navigation Bar, darf hier keine Pfeil-nach-Links Form haben
    • Ist nach THM Login grün
      • Hebt sich farblich nicht vom "Go!" Button ab
      • Grün ist die falsche Farbe, da in diesem Context nicht der Positive Button
  • "Session-ID" oder "Session ID" - Schreibweise nicht einheitlich
  • "Go!" ist ein Verb, beschreibt aber nicht die Aktion. "Session betreten" wäre in diesem Fall besser.














Logout

Arsnova logout.jpg
  • Farbe der Buttons nicht korrekt
  • Buttons sind nicht mit Verben beschriftet









Session Übersicht

Arsnova sessions.jpg
  • Der Button "Logout" taucht doppelt in der Navigationsstruktur auf
    • Sorgt für Verwirrung
    • Alternative hier vielleicht: "Exit"/"Verlassen"








Neue Session anlegen

Arsnova createnewsession.jpg
  • View hat keine Überschrift
  • Placeholder in Labels ist falsch
    • "digits" bedeutet Ziffern, hier ist die Eingabe von Text erforderlich
  • Beschriftung des Buttons
    • Beschreibt nicht den Kontext
    • "Create Session" / "Session anlegen" sind hier bessere Alternativen





Session Startseite

Arsnova sessionoverview.jpg
Arsnova sessionoverview2.jpg
  • Überschrift enthält einen Indikator (Nummer in Klammern)
    • Title-Label ist ausschließlich dem Titel vorbehalten
    • Dieser sollte oben rechts platziert werden
  • Außenabstand oberhalb und unterhalb des "Test" Labels ist unterschiedlich und erzeugt Unruhe
  • "Flashcards" Button hat nicht die Mindesthöhe von 44px
    • Ahmt durch Form und Positionierung ein TableItem nach
  • Die drei unteren Buttons "Instant question", "Lock session" und "Delete session" haben keine Einfassung
    • Icons sind generell sehr unterschiedlich (Form, Schatten) und erzeugen Unruhe













Feedback

Arsnova myfeedback.jpg
  • Label der Feedback Buttons ist nicht zentriert
  • Farbliche Unterscheidung anhand des kleinen Glühbirnen Icons nur schwer möglich









Mensa

Arsnova canteen.jpg
  • "THM Mensa Gießen" ist die Überschrift und muss auch im Title Label der Navigation Bar stehen
  • "I recommend..." Button ist im rechten Bereich der Navigation Bar zu platzieren










Design Kritik ARSnova 1 Desktop

Das auf SenchaTouch basierende ARSnova1 wird aktuell nicht nur für mobile Endgeräte, sondern auch für Desktopbrowser eingesetzt. Hierdurch entstehen einige Designprobleme, die vor allem die Breite der Buttons und Navigationselementen betrifft. Die auf mobile Endgeräte abgestimmten Elemente wirken überdimesnioniert.

Login

Arsnova1 desktopbrowser login.png
  • Login-Buttons ziehen sich über komplette Breite des Desktops
  • Gast-Login dadurch kaum noch als Button zu erkennen
  • "Rolle wechseln"-Button im Verhältnis zu klein









Rollenauswahl

Arsnova1 desktopbrowser rollen.png
  • Buttons ziehen sich über komplette Breite des Desktops
  • "ARSnova@YouTube"-Button im Verhältnis zu klein










Session betreten

Arsnova1 desktopbrowser session beitreten.png
  • Auswahl der bereits besuchten Sessions zieht sich über die komplette Breite des Desktops
  • Größenverhältnis zwischen Session-ID-Eingabefeld "Los"-Button und besuchte-Sessions-Liste stimmt nicht










Logout

Arsnova1 desktopbrowser logout.png
  • Keine weiteren Unauffälligkeiten im Desktop-Browser











Session Übersicht

Arsnova1 desktopbrowser übersicht.png
  • Beide Listenelemente werden über die volle Breite des Desktops dargestellt











Neue Session anlegen

Arsnova1 desktopbrowser session erstellen.png
  • Eingabefelder ziehen sich über maximale Breite des Desktops











Session Startseite

Arsnova1 desktopbrowser startseite.png
  • Beide Listenelemente, sowie der Lernkartei-Button werden über die volle Breite des Desktops dargestellt
  • Session-Name wirkt zwischen Header und den großen Listenelmenten etwas verloren (vor allem bei kurzen Namen)










Feedback

Arsnova1 desktopbrowser feedback.png
  • Sehr geringer Abstand zwischen allen Buttons und dem Header
  • Buttons ziehen sich über die komplette Breite des Desktops. Sind insgesamt kaum noch als Buttons zu erkennen, sondern wirken wie eine große graue Fläche.










Mensa

Arsnova1 desktopbrowser mensa.png
  • Keine weiteren Unauffälligkeiten im Desktop-Browser
  • Positiv: Diagramm skaliert sehr gut und passt sich optimal der Größe des Browserfensters an










Info

Arsnova1 desktopbrowser info.png
  • Liste zieht sich über gesamte Breite des Desktops











Fragenübersicht

Arsnova1 desktopbrowser fragen übersicht.png
  • Listenelemnt über komplette Breite
    • Anders als auf allen anderen Seiten hier auch ohne Rand links und rechts










Neue Frage

Arsnova1 desktopbrowser neue frage.png
  • Eingabefelder ziehen sich über komplette Breite des Desktops
  • Speichern-Button zieht sich über komplette Breite des Desktops
  • Insgesamt wird sehr viel Platz benötigt für verhältnismäßig wenige Eingaben









Frage bearbeiten

Arsnova1 desktopbrowser frage.png
  • Alle Eingabefelder ziehen sich über komplette Breite des Desktops
  • Antwortliste über volle Breite
  • Insgesamt wird auch hier wieder sehr viel Platz benötigt für wenige Eingaben
  • Fragentext zu dicht am Header
    • Text an dieser Stelle überhaupt nötig?
  • Buttons sehr weit außeinander
    • Aufgrund des großen Abstands zwischen den Button ist es sehr schwierig die verschiedenen Optionen die zur Verfügung stehen zu erfassen





Design Guideline ARSnova 2

Buttons

Buttons (ARSnova 1)
Buttons (ARSnova 1)
  • Label ist ein Verb ("Speichern", "Abbrechen" anstelle von "Ja" oder "Nein")
  • Haben einen Hover- und Click-State (wie in der realen Welt)
  • Müssen sich durch Farbe und Typografie abheben
  • Haben eine Einfassung
  • Wichtige Call-to-Action (CTA) Elemente haben durchgehend die gleiche Farbe
  • Sind dreidimensional gestaltet
  • Haben eine maximale Breite (Desktop-Browser)
  • Reihenfolge bei Buttongruppen: NEGATIV - NEUTRAL - POSITIV
    • POSITIV bringt den User zum nächsten Screen
    • NEUTRAL bricht die aktuelle Aktion ab
    • NEGATIV bringt den User zurück zum ursprünglichen Screen
      • Mapping ist somit analog zum Verhalten des Browsers (Back und Forward Button) und des westlichen Richtung-Verhaltensmuster
      • Keine großen Abstände zwischen Button Gruppen, Zusammengehörigkeit muss erkennbar sein
  • Größe der Buttons:
    • Minimum von 44px x 44px nach iPhone Human Design Guidelines[1]
    • Besser:
      • Durchschnittliche Breite des menschlichen Zeigefingers bei Erwachsenen[2]:
        • 1.6 - 2.0 cm (45 - 57 Pixel bei 72 DPi)
      • Durchschnittliche Breite des menschlichen Daumens bei Erwachsenen
        • 2.5 cm (72 Pixel bei 72 DPi)
      • Fitt's Law beachten




Navigation Bar

Navigation Bar (ARSnova 1)
  • Zeigt Titel der aktuellen View
  • Titel ist zentriert
  • Verhalten wenn Benutzer eine Ebene weiter navigiert:
    • Titel ändert sich und zeigt nun den Titel der aktuellen View
    • Auf der linken Seite erscheint ein Zurück-Button, der mit dem Titel der vorherigen View benannt ist
  • Überladen der Navigation Bar vermeiden
    • Links: Falls nötig ein Zurück-Button
    • Mitte: Der Titel der aktuellen View
    • Rechts: Ein Button um den Content der aktuellen View zu bearbeiten ("Edit/Done", "Refresh", …)
  • Der Zurück-Button muss als solcher zu erkennen sein (entsprechende Einfassung, Pfeil-nach-Links-Form)




Tab Bar

Tab Bar
  • Einsetzen um Informationen auf Wurzelebene anzuzeigen (Navigationshierarchie vereinfachen)
  • Maximal 5 Buttons (wenn mehr werden 4 angezeigt, der 5. ist mit "Mehr" zu benennen)
  • Immer alle Buttons anzeigen. Falls die aktuelle Funktion nicht verfügbar ist eine entsprechende View anzeigen (Was muss ich tun damit die Funktion verfügbar ist?")
  • Neue und ungesehene Inhalte in den verschiedenen Views hinter den TabBarButtons werden unaufdringlich über ein Badge angezeigt









Farbschema

  • Navigation Bar
    • Linearer vertikaler Farbverlauf (hell zu dunkel)
  • Tab Bar
    • Linearer vertikaler Farbverlauf (hell zu dunkel)
  • Hintergrund
  • Buttons
    • Linearer vertikaler Farbverlauf (hell zu dunkel; onPress: dunkel zu hell)
    • RGB-Farbschema
  • Liste
  • Eingabefelder



Desktop Browser

ARSnova2 soll mit allen gängigen Browsern nutzbar sein. Dies beinhaltet nicht nur Desktopbrowser, sondern auch die Browser mobiler Endgeräte. Durch den Einsatz von dojo mobile entstehen wie auch bei ARSnova1 einige Designprobleme bei Desktopbrowsern. Um diesen vorzubeugen müssen während der Programmierung folgende Richtlinien beachtet werden:

  • Navigation Bar und Tab Bar, sowie der dazwischen liegende Contentbereich benutzen die volle Breite und Höhe des Browserfensters.
  • Die Breite von Buttons, Listen und Eingabefeldern ist auf maximal 400 Pixel zu begrenzen.
  • Dojo-Widgets müssen vor dem Einsatz auf Kompatibilität und Funktionstüchtigkeit in allen Browsern getestet werden. Ist das entsprechende Widget in einem Browser nicht bedienbar, muss eine alternative Bedienmöglichkeit zur Verfügung gestellt werden.
  • Alle Elemente im Contentbereich sind zentriert ausgerichtet.




Design Vorschläge ARSnova 2

Login / Rollenauswahl

Es wurden 3 verschiedenen Designvarianten für die Login und Rollenauswahl entwickelt. Das auffällige Design der Buttons soll sich später in der ganzen Applikation wiederfinden.

Variante 1

Login Screen (Var. 1)
Roleselect Screen (Var. 1)

Variante 2

Login Screen (Var. 2)
Roleselect Screen (Var. 2)

Variante 3

Login Screen (Var. 3 - Transparent 50)
Login Screen (Var. 3 - Transparent 70)
Login Screen (Var. 3 - Transparent None)

DWX 2013

S. http://www.developer-week.de/. Einreichung bis 05.11.2012. Es handelt sich um eine Entwickler-Konferenz, daher Fokus auf Techniken und Tools. Zeitplan:

  1. Abschnitte fertiggestellt bis 26.10.2012
  2. Überarbeitung bis 01.11.2012
  3. Abschluss-Review bis 04.11.2012
  4. Einreichung: 04/05.11.2012

Dieser Abschnitt ist nach Google Docs umgezogen!

TED im Hörsaal: Implementierung eines massiven Audience Response Systems für deutsche Hochschulen

(Arbeitstitel) Weitere Vorschläge bitte ohne Bewertung hier anfügen:

  • TED im Hörsaal: Implementierung eines mobilen Audience Response Systems für deutsche Hochschulen
  • TED im Hörsaal: Implementierung eines massiven Audience Response Systems
  • TED im Hörsaal: Implementierung eines mobilen Audience Response Systems
  • ...

Einleitung

  • Was ist ARSnova? Audience Response System als Smartphone-Browser-App; TED-System entwickelt von der THM. Im Desktop-Browser und auf dem Smartphone gleichermaßen benutzbar. Features sind auf die realen und didaktischen Anforderungen der Lehre abgestimmt. Open Source und SaaS.
  • Die Vision: Das System für alle Hochschulen so kostengünstig wie möglich anbieten, Ersatz für herkömmliche, proprietäre und mitunter teure Hardware-Clicker. Bring Your Own Device (BYOD): Keine logistischen Probleme mehr.
  • Erste Version: JavaScript + minimales PHP-System für Authentifizierung und Benutzung externer Dienste + CouchDB. Vorteil: Enorm viele gleichzeitige Benutzer bei geringer Hardware-Anforderung. Nachteil: Client beliebig manipulierbar, wenig Sicherheit, mangelhafte interne Qualität.
  • Zweite Version: Verlagerung der "Geschäftslogik" auf einen Java-Server. "Thin-Client" + Websockets für Echtzeit-Kommunikation
  • ARSnova wird von Personen benutzt, die nur geringe technische Kenntnisse haben. Die Bedienung muss daher so einfach wie möglich sein.
  • Software muss so robust wie möglich gestaltet sein, für Probleme wird im Zweifel die Software verantwortlich gemacht, z.B:
    • Problem ist oftmals nicht der Server, sondern die lokale WLAN-Infrastruktur. Können 100+ gleichzeitige Personen das WLAN einwandfrei benutzen? Bei Verbindungsproblemen wird der Server/das System als Problem ausgemacht.
    • Anderes Problem: Mein Feedback-Diagramm sieht anders aus als das des Nachbarn bzw. was am Beamer zu sehen ist. Fehler in der Software?

Achitektur-Übersicht

Welche Anforderungen an das System gibt es?

Um ARSnova betreiben zu können sind folgende Serverapplikationen notwending:

  • Apache Tomcat Servlet-Container
  • Apache Webserver
  • Apache CouchDB


Hierbei muss nicht zwingend die oben genannte Anwendung verwendet werden, alternativen Anwendungen (Jetty als Ersatz zu Tomcat, Lighttpd anstelle von Apache Webserver) können verwendet werden, werden jedoch nicht offiziell unterstützt.

Der Server, auf dem ARSnova betrieben werden soll, sollte, je nach Anforderung und geplanter Benutzeranzahl mindestens 1024 MB RAM aufweisen. Bei einer typischen Installation mit einer Linux-Distribution sollte die Festplatte mindestens 8GB Speicherplatz zur Verfügung stellen.

Zu beachten ist hierbei, dass der Servlet-Container zunächst viel Arbeitsspeicher benötigt, im laufenden Betrieb jedoch kaum neuen Speicher vom System anfordert.

Mit den oben genannten Mindestanforderungen an das System konnten wir unter Zuhilfenahme von Lasttests zeigen, dass über 2000 gleichzeitige Benutzer das System permanent bedienen können. ARSnova, bzw. der in JavaScript verfasste Web-Client, ist jedoch darauf ausgelegt, in großen Teilen keinen ständigen Kontakt zum Server zu benötigen. Es können also gleichzeitig (innerhalb von 1-2 Sekunden) 2000 Benutzer eine Aktion auf dem System durchführen.

Wie wird die hohe Performance erreicht?

Die genannte Anzahl von 2000 gleichzeitigen Anwendern, hier definiert als 2000 quasi-parallele Aktionen durch die Anwender, wird durch ein effektives System der Client-Server-Kommunikation erreicht. Hierbei ist zwischen ARSnova 1 und dem Nachfolger ARSnova 2, welcher sich derzeit in der Entwicklung befindet, zu unterscheiden. Bei ARSnova 1 wurden alle statischen Inhalte, also HTML-Dateien, JavaScript und CSS-Styles, vom Webserver ausgeliefert und konnten vom Browser im Cache gehalten werden. Zudem wurde Gebrauch vom HTML5-Anwendungscache gemacht. Lediglich die eigentlichen Nutzdaten wurde im laufenden Betrieb ausgetauscht. Dies geschah grundsätzlich über die direkte Kommunikation mit der CouchDB, welche alle Anfragen über die REST-Schnittstelle abwickelt. Lediglich zur Anmeldung über den Hochschulaccount wurde PHP verwendet, wobei hier für jede Anfrage ein Serverprozess gestartet werden musste. Die Zeit wurde jedoch nur zu Beginn einer Sitzung aufgewendet, die weitere Interaktion erfolgte grundsätzlich direkt mit CouchDB und erzielte hierbei eine sehr hohe Performance. Dies hatte jedoch zur Folge, dass es potentiell möglich war, unter Kenntnis einiger anwendungsspezifischer Internas, das System gezielt zu manipulieren, da eine sicherheitskritische Überprüfung von Änderungen in der Datenbank nicht erfolgte. Zu diesem Zweck wurde bereits bei der Planung des Nachfolgers ARSnova 2 Wert auf eine zeitgemäße Umsetzung eines Sicherheitskonzepts Wert gelegt, welches in Teilen nun auch auf ARSnova 1 angewandt wird und als Teil von ARSnova 2, nach einer Überarbeitung, weiter Verwendung findet. ARSnova 2 – und damit auch eingeschränkt ARSnova 1 als Teil von ARSnova 2 – ist als Java Web-Anwendung implementiert.Hierdurch profitiert ARSnova von der im Vergleich zu PHP höheren Ausführungsgeschwindigkeit, welche es zudem ermöglicht, ein erweitertes Sicherheitskonzept zu integrieren, ohne nennenswerte Performanceeinbußen hinnehmen zu müssen.

Welche Möglichkeiten der Kommunikation gibt es?

Neben einer guten Performance und einem ständig weiter ausgebauten Sicherheitskonzept wurde für ARSnova 2 die Verwendung von WebSockets integriert, welche eine Echtzeitkommunikation mit dem Server erlauben. Hierdurch ist es möglich, bestimmte Informationen in Echtzeit an andere Clients weiterzugeben, ohne darauf warten zu müssen, dass der Client diese explizit anfordert – ein weiterer Schritt in Richtung ressourcenschonende Client-Server-Kommunikation welche zudem eine neue Anwendererfahrung im Bereich Web-Anwendungen ermöglicht. Die Kommunikation läuft nicht nur objektiv schneller ab, auch der Anwender hat subjektiv die Erfahrung einer flüssigeren Interaktion mit dem System, da ein Warten auf clientseitige Anfragen an den Server entfällt. Neben der Verwendung von WebSockets wurde und wird bei der Entwicklung von ARSnova 2 Wert auf eine durchgängige und strukturierte REST-API gelegt, welche ermöglicht, sämtliche Kommunikation über das HTTP-Protokoll abzuwickeln. Eine Anbindung beliebiger Client-Anwendungen ist daher möglich, sofern diese das HTTP-Protokoll zur Kommunikation verwenden können.

Wie ist die Anwendung intern Aufgebaut?

ARSnova wird als WAR-Paket ausgeliefert und kann in nahezu jedem gängigem Java-Servlet-Container installiert werden. Intern besteht das Projekt aus drei Teilprojekten, welche sich gegenseitig ergänzen und hier anhand ihres Namens im Repository genannt werden:

  • arsnova-legacy-js
  • arsnova-js
  • arsnova-war

Der erste Teil arsnova-legacy-js beinhaltet die JavaScript-Implementierung von ARSnova 1, welche für die Verwendung innerhalb von ARSnova 2 angepasst wurde. So wurden zum Beispiel alle PHP-Scripte für die Authentifizierung über den Hochschulaccount entfernt, da diese Funktionalität an anderer Stelle optimiert implementiert wurde. Das Teilprojekt arsnova-js ist der sich derzeit in der Entwicklung befindliche Teil ARSnova 2. Zusammengefasst wird dies in arsnova-war. Alle Teilprojekte sind als Java-Webanwendung konzipiert. Beim Erstellen von arsnova-war werden die beiden anderen Teilprojekte als sogenanntes Overlay in das resultierende WAR-Paket als statischer Inhalt – es handelt sich hierbei um HTML-Dateien, JavaScript und CSS-Style-Dateien – integriert. Die serverseitige Implementierung befindet sich ebenfalls in diesem Teilprojekt und wurde mit Hilfe des Spring-Frameworks realisiert. Hier kommt Spring-MVC und Spring-Security maßgeblich zum Einsatz. Zusammengehalten wird das Projekt durch Apache Maven, welches automatisiert alle Abhängigkeiten bereitstellen, Tests ausführen und das Projektlayout für verschiedene IDEs bereitstellen kann und für das Zusammenfassen der Teilprojekte verantwortlich ist.

Der Web-Client

ARSnova setzt von Beginn an auf moderne Smartphones, um eines der zentralen Probleme regulärer Hardware-"Clicker" zu umgehen: die notwendige Logistik (verteilen, einsammeln, Batterien aufladen) entfällt komplett, da jeder Zuhörer seinen eigenen Client besitzt. Die Umsetzung als Web-App erlaubt den schnellen Zugriff ohne vorherige Installation aus einem App-Store. Lediglich die sog. Session-ID, eine achtstellige Zugangsnummer, muss noch bekanntgegeben werden.

ARSnova 1 wurde mit dem JavaScript-Framework Sencha Touch umgesetzt, der die Erstellung von Anwendungen mit iOS-ähnlicher Oberfläche erlaubt. Eine zunächst nicht als Problem wahrgenommene Einschränkung des Frameworks ist jedoch, dass nur Browser mit WebKit-Engine unterstützt werden. Da unter iOS und Android in der Regel WebKit-Browser zum Einsatz kommen, war diese Einschränkung zunächst nicht weiter schlimm. Jedoch stellte sich heraus, dass bei der Nutzung eines Desktop-Browsers genau hier das Problem lag: Die Zielgruppe von ARSnova sind nicht etwa technik-affine Nutzer, die z.B. mehrere Browser installiert haben, sondern genau die Nutzer, nur wenig bis moderate Kenntnis im Umgang mit PCs besitzen. Diese Nutzer sind es, die ARSnova mit Internet Explorer oder Firefox öffnen wollen.

Eine Neu-Implementierung der Client-Aspekte von ARSnova war damit zwingend erforderlich. Die Wahl fiel diesmal auf die Dojo-Bibliothek in der Version 1.8, welche verspricht, alle gängigen Browser zu unterstützen, also auch Internet Explorer, Firefox und sogar Opera.

Eine der stärken von Dojo ist die Vielseitigkeit. Es wird kein vorgegebener Anwendungsaufbau erzwungen, sondern die Anwendung kann frei nach den jeweiligen Anforderungen zusammengestellt werden. Dies verdankt Dojo auch der Verwendung des modernen Modulkonzeptes Asynchronous Module Definition (AMD), welches in immer mehr JavaScript-Bibliotheken und -Frameworks zum Einsatz kommt. Die für die Anwendung erforderlichen Module werden hierbei **on demand** nachgeladen, so dass lange Ladezeiten besonders beim Start der Anwendung minimiert werden. Des Weiteren werden HTML 5 APIs angeboten, die für ältere Browser auch in abwärtskompatibler Form zur Verfügung stehen.

Zentrales Element von ARSnova 2 ist der Einsatz von Websockets. Diese erlauben die Echtzeitkommunikation zwischen allen Zuhörern und dem Dozenten und lösen ein besonderes Problem der Pull-Architektur von ARSnova 1: Wird das Feedback-Diagramm für alle Teilnehmer sichtbar projiziert, entsteht der Effekt, dass von einem Teilnehmer abgegebenes Feedback zunächst nur in seinem eigenen Diagramm erscheint. Erst mit einiger Verzögerung erscheint das Feedback bei allen übrigen Benutzern, was nicht selten zu Verwirrung führte. Websockets lösen dieses Problem, da neu eigegangenes Feedback via Broadcast unmittelbar an alle übrigen Benutzer verteilt werden kann. Die zum Einsatz kommende Bibliothek socket.io sorgt für die nötige Technik und bietet auch hier wieder die notwendige abwärtskompatibilität an. Unterstützt der Browser keine Websockets, wird Long Polling verwendet.

Die Architektur des Clients wurde bewusst minimal gehalten. Die Anwendung besteht aus HTML-Templates, welche aus von Dojo zur Verfügung gestellten sowie eigens implementierten Widgets besteht. Views bilden den JavaScript-Teil hinter den Templates und bearbeiten etwa Benutzereingaben oder definieren, welche View nach einer Aktion als Nächstes geöffnet wird. Daten erhalten die Views ausschließlich über interne Ereignisse. Das "Backend" des Clients kommuniziert mit dem Server über Websockets und regulären HTTP-Requests und generiert aus den erhaltenen Daten Ereignisse, welche von den Views empfangen werden können. Die Ereignisse dienen somit als Schnittstelle, welche die Views vom Rest der Anwendung entkoppeln.

Diese Ereignis-Architektur hat den Zweck, den Client möglichst erweiterbar zu halten, dabei so wenig Geschäftslogik wie möglich selbst zu implementieren und statt dessen den Fokus auf die Aspekte Design und Usability zu legen.

Design- und Usability-Kriterien der mobilen Anwendung

Anlehnung an Apple-Guidelines

Um den Usern eine möglichst einfache Benutzung von ARSnova zu ermöglichen, werden während der Entwicklung ausgewählte Teile der Apple Style Guideline berücksichtigt. Das Schema jeder einzelnen View ist identisch. Sie besteht aus der Navigation Bar, dem Content-Bereich, sowie der Tab Bar.

Die Navigation Bar enthält immer den Titel der aktuellen View. Neben dem zentriert ausgerichteten Titel, können optional ein Zurück-Button (linke Seite) oder ein Button um den Content der aktuellen View zu bearbeiten (rechte Seite) hinzukommen. Der Zurück-Button muss durch eine entsprechende Einfassung sowie der Pfeil-nach-Links-Form als solcher zu erkennen sein.

Die Tab Bar wird eingesetzt um Informationen auf Wurzelebene anzuzeigen. Hierdurch wird die Navigationshierarchie vereinfacht. Sie enthält maximal fünf Buttons. Sollten mehr als fünf Buttons benötigt werden, werden die ersten vier Buttons angezeigt und der Fünfte wird mit “Mehr” gekennzeichnet. Neue und ungesehene Inhalte in den verschiedenen Views hinter den Tab Bar-Buttons werden unaufdringlich über ein Badge (Indikator) angezeigt.

Der Content-Bereich wird so übersichtlich wie möglich gestaltet. Es werden nur Standard-Elemente, wie sie auch im iOS-Repertoire zu finden sind eingesetzt. Der Hintergrund ist in allen Views einheitlich. Eine unauffällige Hintergrundfarbe unterstützt das minimalistische Design der Applikation. Die Buttons in ARSnova werden als stilistisches Mittel eingesetzt. Alle Buttons müssen bestimmte Kriterien erfüllen.

  • Label ist ein Verb ("Speichern", "Abbrechen" anstelle von "Ja" oder "Nein")
  • Müssen sich durch Farbe und Typografie abheben
  • Sind dreidimensional gestaltet und haben eine Einfassung
  • Keine großen Abstände zwischen Button-Gruppen. Die Zusammengehörigkeit muss erkennbar sein
  • Reihenfolge bei Button-Gruppen: NEGATIV - NEUTRAL - POSITIV
    • POSITIV bringt den User zum nächsten Screen
    • NEUTRAL bricht die aktuelle Aktion ab
    • NEGATIV bringt den User zurück zum ursprünglichen Screen
  • Einhaltung bestimmter Größenvorgaben
  • Minimum von 44px x 44px nach iPhone Human Design Guidelines

Cross-Browser-Support

Der Client muss vielen verschiedenen Anforderungen gerecht werden, so steht neben der Usability auch der Cross-Browser-Support im Vordergrund. In der ersten Version von ARSnova wurde das Framework Sencha Touch benutzt. Sencha Touch ermöglichte das Implementieren einer HTML5-Applikation mit dem Look&Feel einer iOS-Applikation. Leider beschränkt sich die Unterstützung nur auf aktuelle Webkit-Browser. Daher erfolgt in der zweiten Version von ARSnova eine Portierung in das dojo-Framework, welches eine höhere Browserkompatibilität bietet. So wird neben Webkit-Browsern auch Firefox, Internet Explorer und Opera unterstützt, sowie diverse mobile Browser. Mit dojoX/mobile können analog zu Sencha Touch iOS-ähnliche Applikationen implementiert werden.

Design-Reviews

Durch wöchentliche intensive Design-Reviews und den Erfahrungen aus der ersten Version von ARSnova wird das Design während der Neuentwicklung stetig angepasst. Feedback zu ARSnova1 hilft hierbei die Usability zu verbessern. Erkannte Designfehler und Schwächen werden somit fortlaufend behoben.

Usability

Primäres Ziel ist es eine einfach zu bedienende Applikation zu erschaffen, welche auch von Nicht-Informatikern problemlos bedienbar ist. Wegen der Einfachheit und Übersichtlichkeit fiel die Entscheidung die ursprünglich nur für mobile Geräte optimierte Version von ARSnova auch auf dem Desktop zu nutzen. Durch die natürlichen Restriktionen auf mobilen Geräten und der dadurch nur geringen Anzahl Bedienelemente auf einer Seite ist eine einfache Bedienung sowie eine gute Übersichtlichkeit gewährleistet.

Probleme

Aufgrund des Einsatz von dojo mobile entstehen wie auch bei ARSnova1 einige Design-Probleme bei Desktopbrowsern, die vor allem die Breite der Navigations- und Listenelementen, sowie Buttons betrifft. Die auf mobile Endgeräte abgestimmten Elemente wirken meist überdimesnioniert. Um diesen Problemen vorzubeugen müssen während der Programmierung einige Richtlinien beachtet werden bzw manuelle Anpassungen an die Vorgaben von dojoX/mobile vorgenommen werden.

  • Navigation Bar und Tab Bar, sowie der dazwischen liegende Contentbereich benutzen die volle Breite und Höhe des Browserfensters
  • Die Breite von Buttons, Listen und Eingabefeldern wird auf maximal 400 Pixel zu begrenzt
  • Alle Elemente im Contentbereich sind zentriert ausgerichtet.

Integration in Learning Management Systeme

  • Jeder kann eine Session anlegen: Fluch und Segen zugleich?
  • Spezielle Anforderung für Hochschulen.
  • Offizielle ARSnova-Sitzung für Kurs soll möglich sein, aktive Nutzung nur für reale Kursmitglieder
  • Technische Umsetzung ("Connector"): Wie soll es aussehen?

Ein grundlegendes Konzept von ARSnova ist, dass jeder Anwender eine Session anlegen kann. Diese Philosophie der Gleichstellung aller Anwender ermöglicht jedem das Anlegen einer ARSnova-Session, ob er nun Dozent ist, Student oder keine Verbindung zu einer Hochschule hat. Es kann jedoch hilfreich sein, das Anlegen von Sessions auf einen bestimmten Personenkreis zu beschränken. Dozenten eines Kurses möchten gegenüber ihren Studenten herausstellen, welche Session zu ihrem Kurs gehört und auch durch verschiedenen Lernplattformen der Hochschulen in der Lehre unterstützt wird.

Um dieses Ziel zu erreichen, ist es notwendig ein erweitertes Anlegen einer Session zu schaffen. Besteht zu einer Veranstaltung ein ensprechender Kurs in einer der Lernplattformen einer Hochschule, so soll es dem Dozenten, und auch nur ihm, möglich sein, seine ARSnova-Session an diesen Kurs in der Lernplattform zu binden und innerhalb von ARSnova als solches auszuzeichnen. Hierzu bleibt es dem Dozenten ebenfalls überlassen, ob er diese Session weiterhin für alle Benutzer freigibt, oder ob er den Benutzerkreis auf Kursmitglieder innerhalb der Lernplattform einschränken möchte.

Umgesetzt werden soll dies mit einheitlichen "Connectoren", welche gezielt die gewünschte Informationen:

  • Wer ist Kursdozent bzw. welche Kurse hat ein Dozent?
  • Wer ist Mitglied in den Kursen einer Lernplattform?

bereitstellen und hierbei kein Ändern einer Lernplattform-Installation erfordern, sondern direkt auf die Datenbank zugreifen.

Migration von ARSnova1 auf ARSnova2

  • Optionaler Zusatz-Abschnitt
  • Zunächst getrennte Infrastruktur (z.B. jew. eigene CouchDB)
  • Altbekanntes Problem der Parallel-Entwicklung: ARSnova1 muss gewartet und erweitert werden, während ARSnova2 den alten Stand noch nicht erreicht hat.
  • Schrittweise Zusammenführung (erst Authentifizierung durch die gleiche Server-Komponente, später einzelne Anfragen ebenfalls durch neuen Server leiten usw.)
  • Notwendig nicht nur aus Entwicklungsperspektive, sondern auch um die neue Architektur frühzeitig im realen Betrieb zu haben. Vermeidung des "Big Bang".

Zusammenfassung

  • ua. welche Hochschulen wollen das System einsetzen?
    • als offizielles Dienstangebot des E-Learning/E-Teaching-Centers: JLU, Uni Marburg, THM, Hochschule RheinMain, Uni Ulm
    • einzelne Lehrstühle: RWTH Aachen, Uni Kiel, FH Lübeck, Martin-Luther-Universität Halle-Wittenberg, Universität Hohenheim ...

Einzelnachweise