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.

Verschiedene Funktionen auf verschiedene Listener aufteilen

Als Grundlage benötigt man zunächst HTML. Dieses dient als Template, auf welches man dann mittels Javascript zugreifen kann. Hierbei sollte man beachten, überlegt mit IDs und Klassen zu arbeiten. Ist ein Event-Listener wirklich nur für ein Element notwendig, ist die ID das beste Zugriffsmittel. Klassen sind aber wichtiger: Oft ist nicht klar, wie viele Elemente eine spezielle Funktionalität haben müssen, daher sollte man für jede Funktion eine Klasse vergeben:

	Klick

$('.send-value').click(function() {
    // Button-Value mittels Ajax senden
});

$('.exclusive').click(function() {
    // Andere Buttons mit Klasse exclusive deaktivieren
});

Man erlangt so einen recht gut strukturierten Code, den man einfach wiederverwenden kann. Zudem vermeidet man riesige Funktionskörper in einem einzelnen Listener, in dem man später kaum etwas wiederfinden kann.

Code nach dem Laden der Seite ausführen

Viele J-Query-Plugins bieten bereits eine recht breite Palette an Events, mit denen man arbeiten kann. Will man eigene Event-Ketten aufbauen, muss man in aller Regel nach dem Laden der Seite beginnen.

$(function() {
    // Dieser Code wird nach dem Laden der Seite ausgeführt
});

J-Query-Mobile hat hierfür noch einige andere Events, die man stattdessen nehmen sollte:

$('#page').bind('pageshow', function() {
    // Dieser Code wird nach dem Laden der Seite ausgeführt
});

Eigene Events auslösen: $.event.trigger

Oft kommt man mit den vorgegebenen Events nicht aus. Vor allem wenn man Code wiederverwenden will, muss man diesen oft in verschiedenen Situationen triggern. Ein Beispiel: Ein Listenupdate wird einmal nach dem Laden der Seite und dann immer wieder periodisch ausgeführt. Daher ist es schlecht, die Update-Funktion in die Document-Ready-Event zu packen:

$(function() {
    $.event.trigger('updatelist');
    window.setInterval(
        function() {
            $.event.trigger('updatelist');
        }, 10000);
});

$('#list').bind('updatelist', function() {
    // Das Listenupdate...
});

Die Funktion $.event.trigger ist hierbei enorm wichtig, in der J-Query-Dokumentation aber kaum zu finden. Diese spricht immer nur von $(selector).trigger(event), welche den Event auf einer konkrete Liste von gematchten Elementen auslöst. Dies ist in aller Regel aber eine denkbar schlechte Lösung, da wir eben bei dem Triggern des Events nicht wissen wollen (und sollten), wer an diesem Event interessiert ist. $.event.trigger hingegen triggert den Event auf allen Elementen, die sich dafür registriert haben.

Auf verschiedene Dateien verteilen

Da die Verteilung auf viele kleine Events zwar übersichtlicher, aber keineswegs kürzer ist, wird die entsprechende Javascript-Datei schnell sehr lang. Hier ist es daher empfehlenswert, die Funktionen irgendwie zu gruppieren und auf verschiedene Dateien aufzuteilen. Bei J-Query-Mobile hat man oft mehrere Einzel-Pages in einer Seite. Hier kann man für jede Einzelseite eine eigene Javascript-Datei erzeugen.

Anschließend kann man den JS-Code dann serverseitig wieder zusammenfassen und komprimieren, um die Netzwerklast zu minimieren.

Auf kleinen Bildschirmen…

Wie man sieht, ist das Ergebnis auf dem Telefon sofort sehr hübsch. Hier für reicht es, der noch etwas knappen Dokumentation zu folgen. Was dort allerdings fehlt, ist ein Hinweis, dass die Emulierung von großen Bildschirmen auf Telefonen deaktiviert werden muss. Hierzu einfach folgendes im Head notieren:

<meta name="HandheldFriendly" content="true" />
<meta name="viewport" 
	content="width=device-width, height=device-height, user-scalable=no" />

… und auf großen Monitoren

Diese einspaltige Aufteilung ist für große Bildschirme denkbar schlecht geeignet. Mit ein paar Tricks kann man hier aber schnell in ein Zweispaltenlayout umwandeln. Hierfür werden die beiden Blöcke „Create a new Event“ und „More…“ nicht in ein Div-Element mit der Content gepackt, sondern wie folgt aufgeteilt:

<div data-role="page" id="create-event">
	<div data-role="header" data-theme="b">
		<h1>Tweedback</h1>
	</div>
	<div data-role="content">
		<div class="content-primary">
			<h2>Create a new Event</h2>
		</div>
		<!-- /div.content-primary -->

		<div class="content-secondary">
			<h2>More...</h2>
		</div>
		<!-- /div.content-secondary -->

	</div>
	<!-- /content -->
</div>

Auf kleinen Geräten macht dies zunächst keinen Unterschied. Nun nutzen wir moderne CSS-3-Weichen, um die beiden Blöcke Primary- und Secondary-Content ab einer bestimmten Auflösung nebeneinander darzustellen.

/* === Device size switches */

@media only screen and (min-width: 768px) {
	.content-secondary {
		float: right;
		padding: 0;
		width: 30%;
	}
	.content-primary {
		float: left;
		padding: 0;
		width: 65%;
	}
}

Natürlich sind noch diverse andere Anpassungen für Laptop und Schreibtischrechner denkbar. So ist die Schrift- und Formulargröße nicht jedermanns Sache und wirkt auf den Screenshots etwas erschlagend. Mit dem angesprochenen Ansatz kann man aber vergleichsweise einfach all sowas erreichen – mit vergleichsweise geringem Aufwand.

J-Query Mobile: Nur der Name ist schlecht

Der Namenszusatz „Mobile“ ist etwas unglücklich: Auch auf großen Rechnern kann man das Framework wunderbar nutzen und einfach moderne Webapplikationen erzeugen, die auf nahezu jeder Plattform laufen.