Server: PHP und MySQL

Die Serverseite, welche Tweedback mit Ajaxdaten versorgt, wurde recht geradlinig und ohne Framework umgesetzt. Sie besticht vor allem durch ihre effiziente Nutzung der Datenbankperformance. Viele, teils recht komplexe Anfragen, wurden fast ausschließlich in einzelne Querys verpackt.

Hierbei hat sich aber vor allem ein Problem in den Vordergrund gestellt: Querys, die statt auf feste Tabellen wieder nur auf wiederum verschachtelte Subquerys zugreifen, sind schwer zu entwerfen und noch schwerer zu warten. Ein Quereinsteiger, der sich mit dem Code beschäftigen will, hat es hier sehr schwer. Hinzu kommt, dass ein Query meist als einzelne, abgeschlossene Aktion angesehen wird und daher im inneren schlecht oder gar nicht dokumentiert ist.

Hier sollten wir künftig mehr auf die Werkzeuge der Datenbanken eingehen und z.B. verschiedene Views und UDFs (User Defined Functions) nutzen.

GUI: J-Query Mobile

Die graphische Oberfläche läuft im Browser und basiert auf der dritten Beta von J-Query Mobile. Dieses befindet sich, wie der Name vermuten lässt, selbst noch in Entwicklung. Ärger gab es bei der Entwicklung dennoch nicht, JQM hat sich als zuverlässiges und intuitives Framework bewiesen.

Grundsätzlich ist eine J-Query-Mobile-Rohling auf Kleinstgeräte ausgerichtet. Um auch größere Displays angemessen bedienen zu können, wurde mit Hilfe von Media-Querys des CSS-3-„Standards“ ein sich selbst anpassendes Layout („Responsive Webdesign“) gewählt.

Alles andere folgt streng den Empfehlungen und Vorgaben des Frameworks.

Funktionsweise von Tweedback

Der Dozent

Der Dozent muss vor seinem Vortrag ein Veranstaltung anlegen, in welcher das Feedback gesammelt wird. Wichtig ist hier vor allem der Eventcode, welcher den Zuhörern mitgeteilt wird um am Event teilzunehmen und Rückmeldungen zu geben.

Anschließend befindet sich der Dozent in der Dozentenansicht der Veranstaltung, in welcher aufgekommene Fragen und Warnungen wie „zu schnell“ oder „unklar“ angezeigt werden. Diese Ansicht ähnelt sehr der normalen Veranstaltungsansicht eines Zuhörers, welche gleich noch gezeigt wird.

Nach einer gewissen Zeit werden Events geschlossen und der Dozent erhält einen Abschlussbericht, in welcher die gestellten Fragen aufgelistet und das Nutzerempfinden bezüglich Vortragsgeschwindigkeit und Verständlichkeit in Graphen dargestellt wird.

Der Zuhörer

Der Zuhörer wird nach dem Aufruf von Tweedback folgendermaßen begrüßt:

Wie bereits erwähnt wurde, muss hier der Eventcode eingetragen werden, der vom Dozenten festgelegt wurde. Zusätzlich hat der Zuhörer die Möglichkeit, seinen Namen oder ein Pseudonym einzugeben. Diese Möglichkeit findet sich im persönlichen Einstellungsmenü, welches über die Schaltfläche oben rechts erreichbar ist.

Die Tweedback-Teilnahme ist vollkommen anonym möglich. Ein wesentliches Ziel war ein Webdienst, der den Nutzer zu keiner Anmeldung oder ähnlichen persönlichen Angaben zwingt.

Nach der Eingabe des Eventcodes befindet sich der Zuhörer in der Veranstaltungsansicht. Hier kann dieser bestehende Fragen sehen und diese durch einen Klick auf den orangefarbenen Bereich unterstützen. So werden wirklich wichtige Fragen immer größer dargestellt.

Um die Fragen möglichst knapp zu halten, kann der Nutzer diese einer Kategorie wie Beispiel oder Erklärung zuordnen, um sich bei der eigentlichen Frage auf das zugehörige Stichwort beschränken zu können. Dies ist auf dem obigen Screenshot rechts unten erkennbar, wo neue Fragen erstellt werden können.

Ein weiteres Konzept sind die Schaltflächen Verständnis und Vortragsgeschwindigkeit: Hier kann der Nutzer sein derzeitiges Empfinden durch einen einfachen Buttondruck ausdrücken. Der Dozent erhält die Zusammenfassung dieser Angaben dann als Information (oder ab einer gewissen Stufe als Warnung).

Weitere Entwicklung

Derzeit ist von unserer Seite keine Weiterentwicklung von Tweedback geplant. Da wir mit dem Erreichten jedoch sehr zufrieden sind, bleibt die Hoffnung, dass das System zumindest genutzt oder im Zuge anderen Studienarbeiten erweitert wird.

Der Code ist einfach und verständlich, zudem gibt es eine ausführliche Entwicklerdokumentation. Somit ist auch eine Veröffentlichung des Codes etwa unter der GPL denkbar und von den Entwicklern generell auch vorgesehen. Da auch der betreuende Lehrstuhl über das weitere Vorgehen nachdenkt, wollen wir diese Entscheidung nicht voreilig im Alleingang treffen. Ein Termin für eine mögliche Veröffentlichung ist daher noch nicht abzusehen.

Analysis-Synthesis-Bridge-Model

Das Brückenmodell beschreibt das Vorgehen während der Anforderungsanalyse, insbesondere der Recherche und des Prototypings. Es ist im wesentlichen eine Vierfeldertafel:

Die Tafel beschreibt die Schritte, die es zu beachten gilt.

1. Man benötigt detaillierte Kenntnisse über die aktuelle Situation, in welcher die Software eingesetzt werden soll. Um Probleme zu beheben, ist es absolut notwendig, diese zunächst genau zu verstehen.
2. Die Situation muss modelliert werden. Es entsteht ein deskriptives Modell, welches die Realität auf das wesentliche reduziert. Dies heißt auch, dass zu behebende Probleme mit modelliert werden und deren Behebung im Modell möglich ist.
3. Aufgrund dieses Modells gilt es Lösungen zu finden und diese in das Modell zu integrieren. Um sicherzugehen, dass ein Ansatz auch wirklich funktioniert, ist hier ein Prototyp ein geeigneter Ansatz.
4. Die gefundenen Lösungen müssen auf ihre Realitätsnähe geprüft werden. Dies beinhaltet selbstverständlich, dass die modellierte Lösung auch wirklich funktioniert. Aber auch andere Aspekte sind wichtig: Wird der Nutzer die Software auch wirklich so nutzen, dass das Problem gelöst wird? Wird dies in angemessener Zeit möglich sein? Sind hierfür ausführliche Schulungen notwendig? Neben der Effektivität der Lösung ist somit auch immer ihre Effizienz in Bezug auf ihre Benutzbarkeit zu beachten.

Unser Vorgehen bei Tweedback

Die ersten drei Schritte macht jeder Software-Entwickler intuitiv richtig. Das Problem ist vor allem der vierte. Auch wir sind bei Tweedback sauber der Vorgabe gefolgt: Wir haben das Problem analysiert, modelliert und eine Lösung auf dem Modell erarbeitet.

Wir haben uns bewusst gemacht, welche Probleme es in Vorlesungen gibt und detailliert beschrieben, welche Fragestellungen bei Studenten aufkommen. Anschließend haben wir die Dozenten betrachtet und uns mit dem Problem auseinandergesetzt, dass diese sich nicht auf Feedback-Bildschirme konzentrieren können, sondern Auf-einen-Blick-Übersichten benötigen.

Das Problem mit dem vierten Schritt

Das Ergebnis war eine detaillierte Vorstellung von Nachrichten, die zwischen Studenten und Dozenten ausgetauscht werden müssen. Diese gilt es nun ein- und auszugeben. Folglich versucht man möglichst knappe und intuitive Darstellungsmöglichkeiten und Eingabemasken zu entwickeln.

Was an sich nicht verwerflich klingt ist aber schnell falsch gemacht: Man baut auf sein eigenes Wissen um Programm- und Nachrichtenstruktur. Man kennt die einzelnen Funktionen des Programmes und bildet diese auf knapp bemessene Formulare ab. Für die Direktevaluierung fragt man sich vor allem eines: Würde ich Funktion x auf der Programmoberfläche finden? Diese Frage unterstellt aber, dass der Nutzer um Funktion x weiß. Dies ist aber vor allem am Anfang keineswegs der Fall.

Nicht „Wie mache ich was?“, sondern „Was kann ich machen?“

Und hier ist vor allem der vierte Schritt wichtig: Man muss sich bewusst werden, wer in welcher Situation mit der Oberfläche arbeiten muss. Es geht darum zu erkennen, was ein Nutzer von einem Programm erwartet. Da er keinerlei Vorwissen über interne Abläufe und Funktionen mitbringt, sucht der Nutzer auf der Oberfläche nach Möglichkeiten, seine Erwartungen umzusetzen. Dabei gilt es ihn an die Hand zu nehmen und Möglichkeiten aufzuzeigen.

Wir wussten um unsere Konzepte: Wir haben die Formulare zur Teilnahme an einer Veranstaltung und Erzeugung neuer Veranstaltungen nebeneinander gestellt. Wir wussten, wann welches zu nutzen ist. Die Frage, ob jeder Nutzer überhaupt den Unterschied versteht, stellt man sich hingegen nicht mehr. Auch unsere nächste Darstellung war für uns klar: Man kann bereits dargestellte Rückmeldungen anderer unterstützen. Folglich sucht man diese Möglichkeit in der darstellenden Feedback-Wolke. Weiß ein Nutzer allerdings nichts von dieser Möglichkeit, wird ihm diese auch verborgen bleiben.

Erwischt man sich bei solchen Problemen, redet man sich schnell damit raus, dass es sich nur um einen Prototypen handele. Aber das verschärft das Problem: Man gewöhnt sich an ein Konzept und hält es für selbstverständlich. Bei der Implementierung möchte man schnell und effizient arbeiten, man möchte fertig werden. Daher ist es aber gerade so wichtig, dass eine effiziente Darstellung des Programms und seiner Funktionen möglichst früh zu durchdenken und zu implementieren. Es sind vor allem Details, die bei der Fertigstellung gerne mal vergessen werden.