Leonardo Sponsoren
Projektname:
eBlackboard - Ein Informationssystem für Schulen
Kategorie:
Technologie
Schule:
Friedrich-List-Schule
Klasse:
Website-Team der FLS
Teamsprecher/-in:
Marius van der Wijden
Lehrer/ -in:
Michael Schlosser
Teammitglieder:
Aleg Perevedentsev
Daniel Knopik
Felix Amend
Felix Müller
Jann Brocksieper
János Adelsberger
Lukas Schreiner
Marc Hoitz
Mustafa Saygili
Niclas Komander
Nicolas Reuter
Pascal Ochmann
Simon Seyer
trennstrich
Projektbeschreibung
zurück
verlinkung
trennstrich
Unser Ziel ist es, eine browserfähige Software für ein Schulinformationssystem für die Friedrich-List-Schule zu entwickeln, mit deren Hilfe wichtige Termine, Nachrichten und Ankündigungen zusammen mit einem aktuellen Vertretungsplan digital an verschiedenen Stellen in der Schule angezeigt werden. Das SchulInfoSystem "eBlackboard" soll auf mehreren Monitoren in der Friedrich-List-Schule laufen, die zentral von einem Content Management System (CMS) gesteuert werden, dadurch ist eine Konfiguration auf Client-Seite nicht notwendig. Das Einstellen der Nachrichten und Ankündigungen soll über einen rechtebasierten Genehmigungsworkflow erfolgen, so dass Lehrer, Schüler oder Sekretärinnen mit einem Benutzeraccount direkt oder erst nach Genehmigung Ankündigungen und Nachrichten einstellen können.


Da die auf dem Markt verfügbaren Lösungen sehr teuer sind und für uns zu wenig Schnittstellen anbieten, haben wir uns entschlossen, die Software selbst zu entwickeln.


Folgende Anforderungen soll das eBlackboard erfüllen:

- automatische Aktualisierung der Vertretungsplandaten aus der Vertretungsplansoftware DaVinci
- Einstellen von Neuigkeiten und Ankündigungen über eine webbasierte, benutzerfreundliche Oberfläche
- Überprüfung und Freischalten der Neuigkeiten und Ankündigungen über einen rechtebasierten Genehmigungsworkflow, so dass Lehrer und Schüler Ankündigungen einstellen können.
- Integration der FLS-Nachrichten, die auf unserer Homepage durch unsere Redakteure eingestellt werden
- ansprechendes grafisches Design, welches dem Corporate Design unserer Schule entspricht
- Zugriff auf die Informationen auch nach Schulschluss über unsere Homepage
- Zeitgesteuertes Ein- und Ausschalten der digitalen Bildschirme


Nutzen und Vorteile für unsere Schule

- Moderne und zeitgemäße Information der Schüler, Lehrer und Eltern auch nach Schulschluss
- Zeitliche Entlastung der Schulleitung, da alle wichtigen schulinternen Informationen in Echtzeit an die eBlackboards in der Schule übermittelt und somit Laufwege gespart werden
- Einbeziehung der gesamten Schulgemeinde, d.h. Schulleitung, Lehrer und Schüler können Informationen von jedem Internet-PC einstellen.
- Ersparnis von Druck- und Kopierkosten


"FLS-Website-Team: Zu einer modernen Schule gehört auch eine moderne Website und wir entwickeln alles selbst"

Das ist das Motto unseres Website-Team. Wir sind Schüler des Beruflichen Gymnasiums der Friedrich-List-Schule und arbeiten als Grafiker, Redakteure, Programmierer und Administratoren projektorientiert an der inhaltlichen und programmiertechnischen Weiterentwicklung unserer Homepage. In den letzten Jahren sind wir stetig professioneller geworden. Daher freuen wir uns über diese Herausforderung.

Unseres bisherigen Entwicklungen können auf unserer Homepage www.fls-wiesbaden.de/website-team nachverfolgt werden.
trennstrich
Projekt Fotos
trennstrich
trennstrich
Projekt Videos
trennstrich
trennstrich
Dokumenten Download
trennstrich
trennstrich
Projekt Blog
trennstrich
24.03.2013 - 22:47 Uhr
Michael Schlosser
Stolz, ein dickes Lob und eine kleine Bitte an die Jury
Die letzten Monate waren das wohl Aufregendste und Spannendste, was ich in meiner Funktion als Verwantwortlicher unseres Website-Teams bisher erlebt habe. Software-Entwicklung und Projektmanagement pur, gepaart mit einem enormen Willlen der Schüler, das eBB fertigzustellen.

Es war alles dabei: Mit vielen Höhen und Tiefen, scheinbar unlösbare Aufgaben, Systemabstürze, Androhung einer Markenklage, wenn wir unseren ersten Projektnamen "digitales schwarzes Brett" weiter verwendet hätten, Kooperationsangebot von der gleichen Firma, um bei der Weiterentwicklung der Schnittstellen zu helfen. Und nicht zuletzt der Bezug der Monitore zum Einkaufspreis von dieser Firma, weil man uns wahrscheinlich nicht zugetraut hatte, das Projekt fertigzustellen und hoffte, die Software künftig in unserer Schule einzusetzen.

Schön war zu sehen, wie das Projekt eine richtige Eigendynamik entwickelt hat, ging es anfangs schon recht zügig voran, waren die letzten sechs Wochen richtig arbeitsintensiv und vor allem produktiv. Freitags und samstags bis spät in die Nacht wurde an dem Projekt gearbeitet, kommuniziert und sich virtuell abgestimmt. Unzählige Ticketbeiträge wurden in unserer Projektmanagementplattform trac geschrieben.

Die einzelnen Teams haben sich wirklich selbst übertroffen, alle Muss- und Wunschkriterien des Pflichtenhefts wurden umgesetzt. Starke Leistung. Und es hat sich wirklich gelohnt. Die Schule besitzt jetzt zwei große eBBs mit einem modernen Design und umfangreichen Funktionalitäten und hat im Vergleich zu den im letzten Jahr eingeholten Konkurrenzangeboten der Schule fast 4.000,00 EUR gespart.

Wir hoffen sehr, dass sich die Leonardo-Jury die Zeit nimmt und sich das Pflichtenheft, die Videos und vor allem die 31 Statusbeiträge durchliest. Denn nur so kann man einen kleinen Eindruck bekommen, was für ein Projekt die Schüler hier gestemmt haben. Dies alles in einer 15minütigen Präsentation darzustellen, wird die nächste Herausforderung sein.

Ein herzliches Dankeschön gilt auch unserer Schulleitung, die uns mit dem Einkauf der 46'-Zoll-Monitore, der Verkabelung usw. vorbildlich unterstützt hat.

Auch ich freue mich unsere eBlackboards ab dem 17. April im Live-Betrieb sehen zu können und kann gar nicht ausdrücken, wie stolz ich auf mein Website-Team bin. Nach diesen erreignisreichen Monaten möchte ich nur noch eins: Ausschlafen ;-)
24.03.2013 - 19:46 Uhr
Marius van der Wijden
Statusbericht 031 (Team Projektmanagement): Abschlussbericht
Nach langen Wochen der intensiven Arbeit am eBB sind wir endlich fertig.
Die letzten Blogeinträge wurden verfasst. Das Testing der einzelnen Komponenten ist abgeschlossen. Zwölf Wochen sind seit unserem ersten Statusbericht vergangen. Es waren zwölf schöne Wochen voller Arbeit, in denen wir uns viel näher gekommen sind. Unsere Programmierer, Grafiker und Redakteure haben mal wieder ganze Arbeit geleistet, damit diese Mammutprojekt in der knapp bemessenen Zeit gelingen konnte. Der virtuelle Informationsaustausch über unsere Projektverwaltungssoftware Trac gelang uns gut. Die eBBs werden am 17. April an den vorgesehenen Stellen installiert. Bis zur Abgabe muss die Präsentation überarbeitet werden und es wird noch ein Zeitraffervideo des eBBs gedreht. Letzte kleine Programmfehler müssen noch ausgemerzt werden, doch im Großen und Ganzen ist das Projekt jetzt abgeschlossen.
24.03.2013 - 19:24 Uhr
János Adelsberger
Statusbericht 030 (Team Grafik): Corporate Design Friedrich-List-Schule
Abschließend noch eine Ausführung über die Arbeit der Grafiker speziell an diesem Projekt. Anfürsich mag die Aufgabe ein Userinterface für eine digitale Anzeigetafel nach einer recht trivialen Arbeit klingen. Ein typisches Briefing für einen Interaktion Designer eben. Die Schwierigkeit bestand insgesamt jedoch nicht darin eine geeignete Oberfläche zu entwerfen, sondern viel mehr darin, diese konform der nicht vorhandenen Corporate Identity unserer Schule zu entwickeln.

Letztlich sah man uns häufig über Typefaces und Farbverläufe diskutieren statt am eigentlichen Projekt arbeiten. Herausgekommen ist also neben einem Userinterface für das eBlackboard ein fast fertiges Corporate Design für die Friedrich-List-Schule inklusive Styleguide ect.
Zunächst sahen wir uns die vorhanden Materialien an und stellten schnell fest, dass außer dem 46 x 52px großen Logo und der FLS-Farbe nicht viel zu finden war. Also setzten wir uns zusammen und überlegten uns was genau wir für das eBB benötigen, denn die entsprechen Materialien benötigten wir zum weiterarbeiten, andere, nicht eBB relevanten Teile der CI konnten warten. Wir kamen zu dem zu folgender Checkliste:

Primäre Ziele:
- Farbverlauf
- Vektorisiertes Logo (Bild-Text-Logo)
- Primär und Sekundärfarbe
- Intro für Demovideos
- Hausschrift (Caption & Bodytext)
- Favicon

Sekundäre Ziele:
- App Icon
- Briefpapier
- Visitenkarte

Die primären Ziele waren für die Weiterarbeit am Userinterface unbedingt notwendig, da dieses zur, früher oder später ohnehin fälligen, CI der FLS passen musste.
24.03.2013 - 19:24 Uhr
János Adelsberger
Statusbericht 029 (Team Grafik): eBB Video
Um einen Überblick über die Funktionen des eBlackboard zu gewähren, entschlossen wir uns einen Film zu machen, in dem man ein wenig mehr über das Arbeiten mit dem eBB erfährt.

Zunächst erstellten wir eine List mit den Inhalten des Videos, und versuchten mit möglichst einfachen Mitteln den Inhalt der jeweiligen Überschriften zu vermitteln:

0. Intro FLS-Wiesbaden
1. "Upload Vertretungen"
2. "eBB Konfiguration"
3. "Rechte für Ankündigungen und News zuweisen"
4. "Ankündigungen erstellen"
5. "News erstellen, ändern und freigeben"
6. "Notausgänge anzeigen mit der "Feueralarm-Seite"

Die entstanden Screencaptures wurden anschließend in Final Cut Pro importiert und mit dem, durch die Entwicklung des Corporate Designs entstanden, Intro versehen. Auch bei den entsprechenden Titeln kam unser CD zum Einsatz. Font, Farbverlauf, Schatten ect. hierfür entwickelten wir ebenfalls im Projektverlauf um Videos wie dieses zu ermöglichen. Dazu in einem weiteren Blogpost mehr.

Für die Vertonung griffen wir auf kostenlose, nicht-kommerizell nutzbare Musik zurück.

Wir entschieden uns dazu, das Video zur Feueralarmseite in ein extra Video zu schneiden, um das Video nicht zu lang zu machen. Außerdem hat es mit dem Normalgebrauch des eBB zunächst nichts zu tun.
23.03.2013 - 19:50 Uhr
Lukas Schreiner
Statusbericht 028 (Team Entwicklung): Fehlerbereinigung
Im Zuge des Endspurts vor der Abgabe unseres Projektes war die Korrektur von Fehlern unabdingbar. Dabei wurden die programmiertechnischen Fehler teilweise ziemlich unterschätzt. Funktionen taten ihre Dienste im normalen Browser, aber zum Beispiel nicht in unserer eBB-Software.

Durch intensive Konferenzen und gemeinsamen Entwicklungsstunden bis teilweise morgens um 3 Uhr konnten glücklicherweise die gröbsten Fehler beseitigt werden, wodurch ein reibungsloses Starten des eBB und das Versenden von Screenshots nun möglich ist.

A) Bisherige Ergebnisse
- Fehler bei der Übertragung von Screenshots behoben
- Fehler beim Starten des eBBs: JavaScript hatte Probleme beim Ausführen von Code
- Zusätzliches Logging von JavaScript in eBB-Log
- Und noch weitere kleinere aufgefallene Fehler

B) Problemfelder
- Alle Probleme wie oben beschrieben soweit erst einmal gelöst.

C) Weitere Aufgaben und Ziele
- Weiterer Tests und Performanceoptimierungen
23.03.2013 - 12:52 Uhr
Daniel Knopik
Statusbericht 027 (Team Projektmanagement): Letztes Treffen vor der Abgabe
Gestern hatten wir die letzte Vollversammlung vor der Abgabe. Wir haben die wenigen Punkte, die noch zu bearbeiten sind an die Entwickler verteilt.

A) Bisherige Ergebnisse
- Erstellung eines Präsentations-Konzepts
- Einteilung der letzten Aufgaben

B) Problemfelder
- Es gibt noch kleinere Programmfehler im eBB, die behoben werden müssen

C) Weitere Aufgaben und Ziele
- Erstellung einer Präsentation für die Vorstellung des eBB
- Aufnahme eines Zeitraffervideos des eBBs im Betrieb während einer Schulpause zur Demonstration bei der Präsentation
- Verfassen der letzten Blogeinträge
22.03.2013 - 21:08 Uhr
Pascal Ochmann
Statusbericht 026 (Team Redaktion & Testing): Ankündigungen & News
Nach reichlichem Arbeiten an der Anzeige der Ankündigungen und News auf dem eBB, wurde es mal Zeit dieses wichtige Feature zu testen. Die News wurden alle sauber und richtig angezeigt. Bei den Ankündigungen war es leider noch nicht ganz stimmig. Zeilenumbrüche wurden falsch gesetzt bzw. falsch dargestellt. Bestimmte Ankündigungen waren gar nicht zu sehen. Das sind aber nur kleinere Fehler, die bestimmt schnell behoben sein werden. Nach langem Testen und Fehlerbehebungen läuft der Genehmigungsworkflow reibungslos. Nicht veröffentliche Ankündigungen und News können durch Personen mit Freigaberechten veröffentlicht oder abgelehnt werden.

A) Bisherige Ergebnisse:

-Anzeige neuer Ankündigungen und News

B) Problemfelder:

-Ankündigungen werden noch nicht richtig dargestellt

C) Weitere Aufgaben und Ziele:

-Personen, die Freigaberechte besitzen, sowie auch Autoren sollen per E-Mail über neue Ankündigungen und News benachrichtigt werden
21.03.2013 - 23:56 Uhr
Simon Seyer
Statusbericht 025 (Team Entwicklung): Client-Steuer-Zentral
In früheren Berichten wurde schon auf diverse Module des eBB eingegangen. Dabei wurde einerseits die Oberfläche an sich, aber auch verschiedenen Programm für die Kommunikation beschrieben. Ein wichtiges Puzzle Teil fehlt aber noch: Die Steuerzentrale. Diese ist wie das eBB auch eine Website und bietet die Möglichkeit, die verschiedenen Clients anzusprechen und diesen Befehle zu schicken.

Wie schon beschrieben registriert sich jeder Client, der zum ersten Mal gestartet wird und wird in diesem Schritt in die Datenbank der Website eingetragen. Damit aber nicht einfach jeder Client sich in das System selbstständig einbinden kann, muss, bevor der Client zum ersten Mal die Oberfläche anzeigt, die Registrierung bestätigt werden. Anschließend kann man dem Client Anweisungen schicken, wie beispielsweise den Bildschirm auszuschalten, zum Feuer-Alarm-Modus zu wechseln oder ihn neu zu starten. Neben diesen direkten Befehlen ist über diese Oberfläche auch die Anpassung der Client-Konfiguration sowie das Einsehen von weiteren Informationen vom Client möglich. Damit kann jeder Client ganz gezielt an seinen Standort angepasst werden.

Damit man seine Aktionen nachvollziehen kann, gibt es Status-Farben (grau, rot, gelb und grün), die den aktuellen Zustand des eBB Client anzeigen. Daneben, und das ist ein besonderer Clou, wird für jeden Client ein Live-Stream der Oberfläche angezeigt. Dafür wird in bestimmten Intervallen ein Bildschirmfoto auf dem Client gemacht und dieses zu der Website hochgeladen. Sowohl die Status-Farben als auch die Bilder aktualisieren sich automatisch, ohne dass die Website neu geladen werden muss. Damit hat man auf übersichtliche Art und Weise die volle Kontrolle über alle Bildschirme, die mit dem System verbunden sind.

Weiterhin dient diese Oberfläche für die Erstellung und Zuweisung von Inhalten für den reinen Inhalts-Modus für zum Beispiel Elternabende oder andere Veranstaltungen. Dafür sollen im oberen Bereich neue Inhalte erstellt und diese dann per Drag'n'Drop auf die einzelnen Clients gezogen werden. Nach dem Umschalten in den Inhalts-Modus wird der Inhalt an den Client übertragen und dort dargestellt.

A) Bisherige Ergebnisse
- Die Oberfläche der Steuer-Zentrale wurde größtenteils implementiert
- Die Steuerung der Clients funktioniert
- Die Konfiguration kann angepasst werden
- Das anzeigen des Live-Stream funktioniert grundlegend, aber noch nicht reibungslos

B) Problemfelder
- Viele kleinere aber keine großen Probleme

C) Weitere Aufgaben und Ziele
- Implementieren der Oberfläche zum Erstellen und Zuweisen von Inhalten
- Fehler in der Oberfläche heben
21.03.2013 - 14:45 Uhr
János Adelsberger
Statusbericht 024 (Team Grafik): Feueralarm & Fullscreenanzeigen
Nachdem das Design des eBB abgeschlossen war, konnten wir uns anderen Features zuwenden. So wird für Elternabende und andere besondere Ereignisse eine Meldung ausgegeben um nähere Informationen liefern. Außerdem erstellten wir eine Seite, die im Falle eines Feueralarms, zusätzlich zu den normalen Schildern, die Fluchtwege kenntlich macht. Durch die Tatsache bedingt, dass das eBB an verschiedenen Standorten aufgestellt wird, waren wir gezwungen die Feueralarmseite so anzupassen, dass sie an jedem beliebigen Ort funktioniert. Ein Demovideo dazu finden Sie oben.

A) Bisherige Ergebnisse:
- Feueralarmseite

B) Problemfelder:
- Verschiedene Standorte des eBB im Schulgebäude und somit Unterschiedliche Fluchtwege

C) Weitere Aufgaben und Ziele:
- Anzeigeseite für Events
17.03.2013 - 00:26 Uhr
János Adelsberger
Statusbericht 023 (Team Grafik): Finales Design & Layout eBB
In den letzten Wochen wurden Detailverbesserungen vorgenommen und das Design zu Ende entwickelt. Im nächsten Schritt können die Entwickler das Design in Code umsetzen. Wichtigster Punkt bei den letzten Feinheiten waren die Animationen um Inhalte zu ändern, so spielt es beispielsweise eine Rolle, ob die Seiten in horizontaler oder vertikaler Richtung wechseln. Hier sollte die natürliche Leserichtung unterstützt, und allgemein das Finden der wichtigen Informationen vereinfacht werden.

A) Bisherige Ergebnisse:
- finales Design

B) Problemfelder:
- keine

C) Weitere Aufgaben und Ziele:
- vollständige Umsetzung in Code
16.03.2013 - 22:51 Uhr
Lukas Schreiner
Statusbericht 022 (Team Entwicklung): Konfigurationsmodul erweitert
Zur einfachen Konfiguration unserer Website entwickelten wir bereits vor einiger Zeit ein eigenes Konfigurationsmodul.
Dieses Modul bietet die Möglichkeit, direkt online auf unserer Website das selbige konfigurieren zu können. Dies wurde notwendig,
weil immer weitere Konfigurationsmöglichkeiten mit der Zeit der Entwicklung hinzukamen.

Im Zuge der Entwicklung des eBBs tat sich ein erneutes Problem auf: wie konfigurieren wir unsere Browser von der Ferne aus?
Jedes Mal per SSH auf den Client anmelden und dann eine Konfigurationsdatei anpassen?
Wir entschieden uns dazu, unser bisheriges Konfigurationsmodul zu erweitern. Bisher konnte unser Konfigurationsmodul nur mit Konfigurationsdateien auf dem
entsprechenden Dateisystem umgehen. Das war mit den eBBs nicht mehr ausreichend. Ebenso waren die Konfigurationen vollkommen anders.

Aufgrund mehrerer eBBs müssen auch mehrere Konfigurationen gespeichert werden. Die Konfigurationen werden auf CMS-Seite in der Datenbank gespeichert. Die eBBs
laden sich die Konfiguration jedes Mal nach dem Einschalten die Konfigurationen ab. Sobald die Konfiguration online verändert worden sind, wird der entsprechende
eBB informiert.

Wie ist nun das neue Konfigurationsmodul strukturiert?
Es gibt ein Kern (Configuration). Dieser Kern verwendet unterschiedliche Vorlagen (Templates) und unterschiedliche Speichersysteme (Storage Engine).
Wir haben aktuell zwei Templates: FLS und EBB. Letzteres beinhaltet die Struktur für die eBBs. Die Templates sind wichtig um bestehenden Konfigurationen auf Gültigkeit zu prüfen und den einzelnen Konfigurationseinheiten auch Standard-Werte zuweisen zu können. Eine Konfigurationseinheit muss immer von festgelegten Datentypen sein. Diese müssen bestimmte Schnittstellen bieten, um Werte lesen und schreiben zu können. Damit kann bei der Eingabe von Werten online in der Weboberfläche entweder Werte zur Auswahl angezeigt werden oder auch die Eingabe geprüft werden. Damit wird immer sichergestellt, dass der Nutzer nichts falsches eingeben kann.

Durch die Erweiterung sind wir nun flexibler im Einsatz des Moduls. Wir können ohne Neuschreiben das bestehende Konfigurationsmodul für die Konfiguration der eBBs weiter nutzen. Bei den Fotos kann auch noch einmal die Struktur betrachtet werden.

A) Bisherige Ergebnisse
- Konfigurationsmodul erweitert
B) Problemfelder
keine.

C) Weitere Aufgaben und Ziele
- Regelmäßiges Prüfen des eBB-Status bei der Steuerung von eBBs.
14.03.2013 - 21:16 Uhr
Lukas Schreiner
Statusbericht 021 (Team Entwicklung): PyTools
Wichtiger Bestandteil unseres eBBs ist unser selbst entwickelter PyTools-Server.

Was ist nun dieser PyTools-Server, der nun schon mehrfach in einigen Statusberichten genannt wurde?

Wie der Name vermuten lässt ist der Server in Python geschrieben. Eine leicht zu erlernende, mächtige Programmiersprache.
Dieser Server ist modularisiert und besteht aus einem Kern und aktuell vier Modulen. Diese Module werden zur Laufzeit geladen, wenn sie benötigt werden.
Jedes Modul hat unterschiedliche Aufgaben. Dabei ist das "dsb"-Modul mit Abstand das mächtigste zum aktuellen Zeitpunkt der Entwicklung. Eine Anfrage an den
PyTools-Server kann synchron, wie auch asynchron erfolgen.

Der Reihe nach:

- xls2array: Nimmt eine Excel-/Calc-Datei entgegen und liest sie ein. Daraus wird ein Array erzeugt und dieses Array wird als Json-String zurück gegeben. Der Aufruf erfolgt synchron. Wir verwenden dieses Modul, um Tabellenkalkulationen in einen Artikel zu importieren.

- checkFile2Todo: Dieses Modul ist ein Entwicklungsmodul. Es wird mit CodeSniffer-Ergebnissen gefüttert und erstellt automatisch eine aktuelle Todo-Liste für Trac und stellt diese online. CodeSniffer ist ein Tool, das Verstöße gegen Programmierrichtlinien und Syntaxfehler erkennt. Es wird also nur in der Entwicklung verwendet. Asynchroner Aufruf möglich.

- tex2pdf: Dieses Modul ist eines der wichtigsten Module. Wir haben mehrere LaTeX-Vorlagen je nach Verwendung erstellt und mit Variablen gefüllt. Dieses Modul wird mit dem Vorlagennamen und den entsprechenden Variablen mit Werten mittels eines JSON-Strings gefüttert. Daraus generiert PyTools eine PDF-Datei und verschickt sie per E-Mail. Dieses Modul wird bei uns für die Kurswahl und -abwahl genutzt. Wir führten es deshalb ein, weil wir ordentliche Dokumente als Beweis und Bestätigung für den Schüler erstellen mussten. Auf PHP-Seite mit Frameworks wollten wir es nicht machen, da es zu aufwendig gewesen wäre. Aus Sicherheitsgründen erfolgt die Dokumentenübermittlung nur noch per E-Mail. Daher erfolgt der Aufruf mittlerweile auch asynchron.

- dsb: Dieses Modul ist mittlerweile ebenso eines der wichtigsten Module und kam neu hinzu. Es verarbeitet sämtliche eBB-Anfragen, hält die Verbindung zu den Clients offen und füttert sie mit Informationen, Anweisungen und Daten vom CMS. Wir haben dies extra von unserer Website abgekapselt, weil wir insbesondere eine eingebaute Multithreading-Funktionalität benötigten. Ebenso wollten wir unseren Webserver nicht zusätzlich beanspruchen. Über die Lösung sind wir sehr erfreut. Der Aufruf erfolgt von Seiten der eBB-Clients synchron. Von Seiten unseres CMS erfolgt der Aufruf asynchron.

Die Verbindung zum PyTools-Server läuft mittlerweile vollständig über openssl-verschlüsselte Verbindung. Im Fall des eBB-Moduls ist sogar eine Authentifizierung per Zertifikat unbedingt erforderlich. Damit werden die Rechte festgelegt.

Zum groben Ablauf: 1.) Client baut Verbindung zum PyTools-Server auf und authentifiziert sich. 2.) Server bestätigt Verbindung. 3.) Client sendet Anfrage. 4.) Je nach Modul erfolgt eine Rückmeldung. 5.) Verbindung wird wieder getrennt.

Durch die in dieses Jahr durchgeführte Modularisierung des Servers ist es nun möglich, Module zur Laufzeit hinzuzufügen oder zu entfernen.

A) Bisherige Ergebnisse
- Umstellung auf neues Konzept erfolgreich.

B) Problemfelder
- Keine

C) Weitere Aufgaben und Ziele
- Konfiguration auch über Config-Dateien statt Parameter.
- Remote-Logging zum CMS
13.03.2013 - 14:28 Uhr
Mustafa Saygili
Statusbericht 020 (Team Redaktion): Vollständige Lehrernamen statt Lehrerkürzel
Beim Hochladen der Daten werden aus dem daVinci-Programm nur die Lehrerkürzel statt den vollständigen Nachnamen in die Vertretungsplan-Datenbank hochgeladen. Damit die ausgeschriebenen Lehrernamen zukünftig auch auf den eBBs zu sehen sind, wurde von den Entwicklern in unserem Kursverwaltungssystem ein Modul programmiert, das die Lehrerkürzel erkennt und sie den richtigen Lehrernachnamen in der Datenbank zuordnet. Nachdem wir über ein Eingabe-Formular über 120 Lehrernamen dort eingepflegt haben, ist es ab sofort möglich, die vollständigen Nachnamen im Vertretungsplan und in den eBBs anzuzeigen.

A) Bisherige Ergebnisse
- Entwicklung eines Lehrernamen-Verwaltungsformulars zum Anlegen, Ändern und Löschen der Lehrernamen
- Für alle Lehrerkürzel wurden die vollständigen Lehrernamen angelegt.

B) Problemfelder
- keine

C) Weitere Aufgaben und Ziele
- Benutzerhilfe erstellen
11.03.2013 - 20:44 Uhr
Lukas Schreiner
Statusbericht 019 (Team Entwicklung): Fragen geklärt. Mit Vollgas geht es weiter
Im vorletzten Bericht unserer Entwicklungsgruppe sind einige Fragen aufgetaucht, die wir nun geklärt haben.

Wie sieht die Kommunikation zwischen den vier Elementen aus (Client, eBB, pyTools-Server, FLS-Seite)?

Zur besseren Veranschaulichung finden Sie bei den Bildern eine entsprechende grafische Aufbereitung.
Im Zentrum steht unser vServer bei einem externen Provider, welcher von uns gewartet und administriert wird.
Auf diesem vServer laufen zwei relevante Dienste: zum Einen der Webserver mit unserem Content-Management-System (nachfolgend mit CMS abgekürzt) und
zum Anderen der bereits angekündigte PyTools-Server. Der Webserver ist mit einer MySQL-Datenbank verbunden.
Die Datenbank enthält für den eBB drei relevanten Tabellen:

fls_dsb_info: enthält aktuelle Informationen zu den einzelnen Clients (IP, Screenshot, Hostname, ...)

fls_dsb_config: enthält die aktuelle Konfiguration je Client. Diese kann sich der Client jederzeit herunterladen.

fls_dsb_clients: enthält die generellen Informationen zum Client (wie ist der aktuelle Status, Hardware-ID, ...)

Ebenso haben wir noch fls_pytools_queue. In dieser Tabelle werden die PyTools-Einträge zwischengespeichert, um (a) die Wartezeit für den Anwender auf der Seite in einem annehmbaren Bereich zu halten und (b) um fehlgeschlagene Anfragen an den PyTools-Server durch zum Beispiel Netzwerkproblemen jederzeit erneut versuchen zu können.

Nun zum eigentlichen Ablauf: beim ersten Start eines eBB-Clients wird eine Anfrage an PyTools über eine openssl-verschlüsselte Verbindung gestellt. PyTools registriert den Client bei sich und hält die Verbindung mit dem Client aufrecht. Anschließend wird die Anfrage an das CMS weitergeleitet und im System registriert. Standardmäßig sind alle Clients deaktiviert. Das heißt, jetzt muss ein Administrator sich im CMS anmelden und den Client freischalten. Jetzt wird eine Benachrichtigung an PyTools gesendet, welcher wiederum den Status des Clients bei sich ändert und die Mitteilung an den eBB weiterleitet.
Ab hier ähnelt sich der Ablauf mit einem bisher registrierten eBBs. Beim Server wird über PyTools die Konfiguration des Clients nachgefragt. Nach einer winzigen Weile wird die Konfiguration übermittelt, der Status auf Online gesetzt und der Client startet den Browser mit der richtigen URL. Ab jetzt sind alle Beteiligten in einem Wartemodus. Alle warten auf Aktionen.

Jetzt kann zum Beispiel im CMS gesagt werden: Client ausschalten. Dann wird vom CMS eine Nachricht an PyTools gesendet, welcher die Nachricht an die richtigen Clients
zeitgleich weiterleitet. Dort werden die Nachrichten zunächst analysiert: ist die Nachricht für den Client oder für die eBB-Seite? Entsprechend wird die Nachricht mittels Webkit und JavaScript weitergeleitet oder im Client selbst verarbeitet. Im Falle der Aktion "ausschalten" wird die Aktion quittiert und eine Nachricht an das CMS mit dem Umweg PyTools gesendet. Sobald ein Client die Verbindung verliert, wird das CMS darüber informiert und der Status entsprechend aktualisiert.

Für das Übermitteln einer Nachricht haben wir uns für ein bestimmtes Format entschieden. Siehe entsprechendes Bild.

In regelmäßigen, konfigurationsabhängig, Abständen wird ein Screenshot des eBBs erstellt und in mehreren Teilen zum CMS mit Umweg PyTools gesendet. Der PyTools-Server überprüft vor dem Upload auf Vollständigkeit der Daten. Dieser Schritt hat uns am Anfang viel Arbeit gekostet, da die Bytes teilweise in der falschen Reihenfolge ankamen, als sie gesendet worden waren.

Soll eine zweite Verbindung per Websocket aufgebaut werden?
Nein. Ist schwierig, da wir sonst immer eine Verbindung offen halten müssten - auch auf PHP-Seite.

Sollten die Verbindungen verschlüsselt werden?
Ja. Unbedingt.

Wie umschiffen wir das Proxy-Problem im Wiesbadener Schulnetz?
Mit Portfreischaltungen in der Firewall. Zur Überbrückung bis dahin wird hierzu ein VPN-Server eingerichtet (siehe späteren Bericht).

Unseren PyTools-Server werde ich zu einem späteren Zeitpunkt detaillierter erklären. Er hat viel Zeit und Aufwand gekostet.

A) Bisherige Ergebnisse
- Kommunikation zwischen Client, eBB-Seite, PyTools, CMS
- Verschlüsselung
- Implementierung des Protokolls

B) Problemfelder
- openssl. Aufgrund einigen Schwierigkeiten waren wir gezwungen, openssl entsprechend eines Bugeintrags manuell zu patchen, damit es einwandfrei lief.

C) Weitere Aufgaben und Ziele
- Benachrichtigung, wenn sich ein Client neu registriert, jedoch deaktiviert ist.
10.03.2013 - 11:35 Uhr
Michael Schlosser
Statusbericht 018 (Team Beschaffung und Verkabelung): Die Monitore inkl. embedded PCs sind eingetroffen
Die bestellten 47'-Monitore der Firma Samsung (Modell SyncMaster 460 MX-3) inkl. Slide-In-Modul(SIM-NT) und Wandhalterungen sind nun endlich eingetroffen.

Da die Strom- und Netzwerkanschlüsse für die beiden eBlackBoards im Eingangsbereich unseres Hauptgebäudes bzw. in der Pausenhalle des Attrium bereits verlegt wurden, haben wir bis auf die Montage den Meilenstein "Beschaffung und Verkabelung" erfolgreich abgeschlossen.

A) Bisherige Ergebnisse
- 2 Monitore inkl. Slide-In-Modul und Wandhalterungen wurden beschafft
- Verkabelung (Strom- und Netzwerk) wurde umgesetzt

B) Problemfelder
- keine

C) Weitere Aufgaben und Ziele
- Freischaltung diverser IP-Ports, um die eBB zentral steuern zu können (Termin für die Freischaltung: 11.03.2013)
- Montage und Anschluss der eBBs nach Fertigstelligung und erfolgreichem Test unserer Software.
08.03.2013 - 22:24 Uhr
Simon Seyer
Statusbericht 017 (Team Entwicklung): Frontend-Entwicklung
Das Frontend ist bei dem eBB deutlich aufwendiger, als bei einer normalen Website. Websites zeigen im Normalfall statischen Inhalt an. Die Inhalte werden also einmal geladen und danach nicht mehr verändert. Beim eBB gehen wir aber genau den umgekehrten Weg: Die Seite wird nur einmal geladen und Aktualisierungen der Daten, geänderte Einstellungen, Wechsel zwischen den Ansichtsmodi und mehr wird im Hintergrund verarbeitet und dann direkt angewandt. Dafür ist es nötig, dass zum einen die Daten vom Server richtig aufbereitet abrufbar sind und zum anderen, dass auf Client-Seite ein Skript sich um die Darstellung kümmert.

Der Ablauf im Überblick:

1. Schritt: Die Website lädt. Es werden eine Schablone des eBB geladen, in der noch keine Daten vorhanden sind. Zusätzlich werden die Style-Daten, die für die ansprechende Darstellung verantwortlich sind, und die Skripte, die in Schritt 2. benötigt werden, übertragen.

2. Schritt: Das Skript, geschrieben in javascript in Kombination mit dem Framework jquery, nimmt seine Arbeit auf. Dafür startet es zuerst eine Initialisierung, in der die Bereiche der Website mit dem Skript verknüpft werden und das Skript fängt an, Anfragen an den Server zu schicken, in denen es um die Daten für den Vertretungsplan, die Ankündigungen und die News bittet. Sobald diese geladen sind, geht das Skript zum Anzeigen der Daten über. Die Daten werden wiederum von dem FLS-Server zur Verfügung gestellt und nach der Verarbeitung im Backend im JSON-Format an das Frontend zurück geschickt.

3. Schritt: Die News und Ankündigungen werden in die entsprechenden Flächen eingefügt und ein Jquery-Plugin, also eine Erweiterung der Skript-Sprache, initialisiert, was sich um die Bewegung zwischen den einzelnen Einträgen kümmert. Alle Bewegungen sind übrigens synchron getaktet, was bei der vielen Bewegung für etwas Ruhe sorgt. Das heißt es gibt fest definierte Punkte, an denen bei den einzelnen Teilen des eBB angefragt wird, ob sie einen Übergang zwischen Inhalten starten wollen. Diese Punkte sind konfigurierbar.

4. Schritt: Ein Algorithmus versucht die Vertretungsplan-Einträge möglichst geschickt in dem zur Verfügung stehenden Platz zu verteilen. Dabei ist erstes Ziel, die Anzahl der Seiten möglichst gering zu halten. Andererseits wird aber auch versucht, möglichst keinen Platz zu verschenken. Beispiel: Sind es so viele Einträge, dass so oder so 2 Seiten benötigt werden, so werden die News und der Header nicht ausgeblendet. Würde das Ausblenden der News hingegen dafür sorgen, dass nur eine Seite benötigt wird, so werden sie ausgeblendet. Der Algorithmus ist so dynamisch, dass er sich auf die jeweilige Display-Größe automatisch einstellt. Bis zu einem gewissen Grad kann sich das eBB also an ganz verschieden große Displays anpassen. Um das zu Erreichen, kann der Bereich mit News und Ankündigungen sowie der Header ausgeblendet werden. Die Zeilenhöhe im Vertretungsplan kann zusätzlich reduziert werden.

5. Schritt: Um diesen Bericht nicht zu lang werden zu lassen, kürze ich das etwas ab: Es greifen noch weitere Algorithmen, die unter anderem dafür sorgen, dass ich jedem Fall die komplette Vertretung lesbar ist. Im Anschluss werden die Einträge entsprechend den Ergebnissen aus Schritt 4. in die Oberfläche eingefügt und das Skript gestartet, welches die Wechsel zwischen den Seiten und Tagen übernimmt.

6. Schritt: Bekommt die Oberfläche die Nachricht, dass sich Daten geändert haben, startet sie ein Update. (Wie sie diese Nachricht bekommt wird in einem anderen Bericht beschrieben) Dieser Schritt wirkt auf den ersten Blick eher trivial, in Wirklichkeit ist er aber maßgeblich daran Schuld, dass das fertig Skript über 1000 Zeilen haben wird. Es ist deswegen so komplex, da nicht auffallen soll, dass ein Update durchgeführt wird. Dafür ist es nötig, an dem Punkt, wo gerade keine Seite gewechselt wird, die gerade nicht sichtbaren Seiten zu aktualisieren, dann eine Seite weiter zu schalten und nach dem Abschluss der Animation die Seite zu aktualisieren, die vorher im Vordergrund war. Da sich die Anzahl und die Reihenfolge der Daten sich ändern kann oder zum Beispiel nach dem Update keine Vertretungen mehr vorhanden sein können, müssen bei der Aktualisierung eine ganze Reihe von Fällen abgedeckt werden.

Dies ist nun der grobe Ablauf. Im Hintergrund passieren noch deutlich mehr einzelne Schritte, die alle zusammen dafür sorgen, dass das eBB wie gewünscht arbeitet.

A) Bisherige Ergebnisse
- Die Standard-Ansicht der Vertretungsplans wurde bis auf ein paar kleinere Aufgaben vollständig implementiert
- Die Feueralarmseite wurde ansatzweise implementiert

B) Problemfelder
- Die ganzen einzelnen Probleme würden diese Seite sprengen, aber hauptsächlich haben wir etwas die Komplexität unterschätzt, die für die Implementierung der Oberfläche nötig ist.
- Zwischenzeitlich gab es etwas Probleme die Vorgehensweise des Plugins zu verstehen, dass für das Wechseln der Seiten verantwortlich ist. Dadurch wurden zum Beispiel Inhalte abgeschnitten oder erst gar nicht angezeigt. Auch das Implementieren der Anzeigen für die aktuelle Seite war nicht ganz einfach.
- Der Code wurde mit der Zeit immer größer und damit ist auch etwas die Struktur verloren gegangen, die bei javascript generell schwerer herzustellen ist als zum Beispiel bei PHP.

C) Weitere Aufgaben und Ziele
- Vollständige Implementierung aller drei Ansichten (Standard, Feueralarm und reiner Inhalts-Modus)
06.03.2013 - 22:11 Uhr
Lukas Schreiner
Statusbericht 016 (Team Entwicklung): Eigener Browser
Aufgrund der Tatsache, dass wir unseren eBB mittels Webtechnologien bereitstellen, benötigen wir einen Browser, der die generierten Seiten auch darstellt.
Hierzu greifen wir nicht direkt auf bestehende Lösungen, sondern entwickeln einen eigenen Browser. Das bietet uns einige erhebliche Vorteile und auch Möglichkeiten. Als Engine verwenden wir Webkit zusammen mit einer
Qt-Oberfläche. Programmiert wurde der Browser in Python.

Was zeichnet diesen Browser nun aus? Der Browser baut eine Verbindung mit dem zentralen Server auf (in diesem Fall unserem Webserver). Von dort erhält der Browser die Konfigurationsdateien, wartet auf Anweisungen, stoppt und startet den eBB und benachrichtigt den eBB über Änderungen (push statt pull).

Damit das Aufrechterhalten der Verbindung zweifelsfrei möglich ist und vor allem multithreadfähig ist, wurde zwischen der eigentlichen Seite und der Hauptseite ein bestehendes Werkzeug von uns geschaltet - natürlich in Python programmiert. Details gibt es in einem weiteren Blog-Eintrag.

A) Bisherige Ergebnisse
- Starten der Oberfläche
- Anzeigen des eBBs
- Lokale Konfigurieren des eBBs
B) Problemfelder und Fragen, die uns quälen
- Wie sieht die Kommunikation zwischen den vier Elementen aus (Client, eBB, pyTools-Server, FLS-Seite)?
- Soll eine zweite Verbindung per Websocket aufgebaut werden?
- Sollten die Verbindungen verschlüsselt werden?
- Wie umschiffen wir das Proxy-Problem im Wiesbadener Schulnetz?
C) Weitere Aufgaben und Ziele
- Fragen klären (keine Sorge, es gibt einen zweiten Blog-Eintrag nach Klärung)
- Gescheite Zwei-Wege-Verbindung zwischen den Systemen herstellen
- Die verschiedenen eBBs steuerbar machen
27.02.2013 - 21:25 Uhr
János Adelsberger
Statusbericht 015 (Team Grafik): Refinement Design & Layout eBB
Nach mehreren Wochen und zahlreichen neuen Entwürfen sind wir nun mit dem Design des eBBs im Großen und Ganzen zufrieden und werden uns in den nächsten Wochen nur noch auf Detailverbesserungen beschränken. Wichtige Änderungen zum Original sind:

- positiver Text für bessere Lesbarkeit
- zweispaltiges Design
eleganteren Header
- Icons zur visuellen Unterscheidung der unterschiedlichen Änderungen
- wegfallende Überschriften für jede Spalte
- Integration wichtiger Informationen wie aktuell angezeigter Tag

A) Bisherige Ergebnisse:
- Integration aller notwendigen Funktionen und Informationen
- Nahezu finales Layout

B) Problemfelder:
- UX Design

C) Weitere Aufgaben und Ziele:
- weiteres Refinement bis zur Umsetzung des Entwicklerteams
25.02.2013 - 21:29 Uhr
Nicolas Reuter
Statusbericht 014 (Team Administration): Installation des Betriebssystems
Da nächste Woche die Bildschirme unseres eBB ankommen sollen, habe ich mich an die Installation des Betriebssystems für die Anzeige auf den Bildschirmen gemacht. Wir verwenden Arch Linux, ein System, welches im Grundzustand gerade mal 120 MB groß ist. Es beeinhaltet nur die grundsätzlichen Dinge, die für Linux notwendig sind, alles andere (wie eine graphische Oberfläche oder zusätzliche Programme) kann man mithilfe des "Package Managers" Pacman (nicht zu verwechseln mit dem gleichnamigen Spiel) installieren. Für unseren Zweck brauchen wir keine "ausgewachsene" graphische Oberfläche wie beispielsweise KDE oder Gnome, an sich müssen wir nur ein Programm ausführen, wofür man nur den Xorg-Server (X11) benötigt. Den habe ich installiert, zusammen mit einem Browser für die Anzeige. Zusätzlich habe ich einen ssh-Server installiert, damit man den Computer aus der Ferne konfigurieren kann. Für den Zugriff müssen noch Ports im pädagogischen Netzwerk unserer Schule freigegeben werden. An sich ging die Installation, auch weil ich dieses Betriebssystem schon öfter installiert habe, reibungslos von sich. Das einzige, was die Installation für mich erschwert hat war, dass der Rechner kein CD-Laufwerk hat, was mich dann dazu gebracht hat, für die Installation einen USB-Stick zu verwenden. Dies hatte ich davor noch nicht gemacht.

A) Bisherige Ergebnisse
Installation des Betriebssystems Arch auf einen der Steuerrechner.
Installation von ssh auf dem einem Steuerrechner
Test der Installation

B) Problemfelder
Installation per USB-Stick
Konfiguration eines Proxys (im Schulnetzwerk)
Freischalten von Ports (im Schulnetzwerk)

C) Weitere Aufgaben und Ziele
ausführlicher Test des Rechners im Einsatz
Klonen des einen Steuerrechners auf den/die anderen.
20.02.2013 - 19:10 Uhr
Aleg Perevedentsev
Statusbericht 013 (Team Grafik): Fertigstellung der Symbole
Wir haben die Konzepte der Symbole überarbeitet und sind zu einem klaren Aussehen gekommen.

A) Bisherige Ergebnisse

Umsetzung der Icons war erfolgreich

B) Problemfelder

keine

C) Weitere Aufgaben und Ziele

Implementierung der Icons in das Design
18.02.2013 - 21:22 Uhr
Michael Schlosser
Statusbericht 012 (Team Beschaffung und Verkabelung): Auswahlentscheidung für die Monitore ist erfolgt, Verkabelung ist bereits umgesetzt
In Abstimmung mit der Schulleitung haben wir uns für ein leistungsstarkes Modell inkl. intergriertem PC entschieden. Die Bestellung der Monitore soll Anfang der nächsten Woche erfolgen, so dass zwei größere 47'-Monitore der Firma Samsung (Modell SyncMaster 460 MX-3) inkl. Slide-In-Modul(SIM-NT) und Wandhalterungen eintreffen werden.

Weiterhin wurden in dieser Woche schon die Strom- und Netzwerkanschlüsse für die beiden eBlackBoards im Eingangsbereich unseres Hauptgebäudes bzw. in der Pausenhalle des Attrium verlegt.

A) Bisherige Ergebnisse
- Auswahl der Monitore ist erfolgt
- Verkabelung (Strom- und Netzwerk) ist umgesetzt

B) Problemfelder
- keine, mit der Beschaffung sind wir im Plan

C) Weitere Aufgaben und Ziele
- Installation von Arch Linux auf den Slide-In-Modulen
- Freischaltung diverser IP-Ports, um die eBB zentral steuern zu können
13.02.2013 - 21:26 Uhr
Aleg Perevedentsev
Statusbericht 011 (Team Grafik): Erstellen von Symbolen
Da wir ein geordnetes und platzsparendes Design bevorzugen, versuchen wir, Icons und Symbole für Dinge wie "Lehrervertretung", "Raumwechsel", "Datumsänderung", "Fachwechsel" und "Stundenausfall" zu erstellen. Diese sollen als Eyecatcher dienen und den Typ der Vertretung leichter erkennbar machen.

A) Bisherige Ergebnisse
- Erstellung einiger Konzeptideen
- Erstellung einer Skizze von Symbolen

B) Problemfelder
- Bedeutung der Icons muss verständlich sein

C) Weitere Aufgaben und Ziele
- Saubere Ausarbeitung der Icons
- Implementierung der Icons in das bereits vorhandene Design
10.02.2013 - 21:49 Uhr
Lukas Schreiner
Statusbericht 010 (Team Entwicklung): Upload der Vertretungsdaten
In unserem eBB soll hauptsächlich der Vertretungsplan angezeigt werden. Nun müssen diese Daten auch auf den Server gelangen. Da unsere Schule für die Erstellung von Vertretungsplänen das kostenpflichtige Programm "daVinci" verwendet, das keine offenen Quellen bietet und auch keine Schnittstellen, mussten wir ein wenig improvisieren. Die an uns gestellte Anforderung: wie bekommen wir die Vertretungsdaten exportiert und fehlerfrei hochgeladen. Nach längerer Entwicklung konnten wir dank verschiedener HTML-Exporten alle relevanten Daten extrahieren. Diese Daten werden automatisch von einen von uns in Python geschriebenem Programm hochgeladen. Unser Uploader arbeitet im Hintergrund, so dass der Anwender nichts weiter tun muss, außer die Daten zu exportieren.

A) Bisherige Ergebnisse
- Interpretieren von Vertretungen
- Interpretieren der abbestellten Klassen
- Upload der Daten

B) Problemfelder
- Nach vermutlich einer Umstellung im Verwaltungsnetz Wiesbaden war ein Upload nicht mehr möglich
- Upload-Problem an sich ist mittlerweile behoben. Jedoch erhalten wir weiterhin einen Fehler 403, der irgendwo im Verwaltungsnetz geworfen wird und somit dem Anwender ein "Uploadfehler" entgegen wirft.

C) Weitere Aufgaben und Ziele
- Beheben des Uploadproblems im Verwaltungsnetz. Das heißt: herausfinden, wo der Fehler 403 gesendet wird.

Die beschriebenen Uploadprobleme beziehen sich wirklich nur auf das Verwaltungsnetz Wiesbaden. Im pädagogischen Netz funktioniert es reibungslos.
04.02.2013 - 19:32 Uhr
Daniel Knopik
Statusbericht 009 (Team Projektmanagement): Website-Team-Sitzung
Wir haben am 1.2.2013 eine Besprechung mit dem gesamten Website-Team abgehalten, in der wir von 10:30 Uhr bis fast 15:00 Uhr die noch offenen Punkte besprochen haben. Nachdem wir den aktuellen Stand der einzelnen Teams angehört und diskutiert haben, besprachen wir die weitere Vorgehensweise und legten einen Terminplan für die noch offenen Meilensteine fest. Die meiste Zeit verbrachten wir damit den neuen Designvorschlag und die noch zu programmierenden Funktionalitäten zu besprechen.

A) Bisherige Ergebnisse
- Pflichtenheft
- Beschluss der Bezugsquelle der Monitore
- Uploadprogramm der Vertretungsplandaten vom Schulleitungsrechner zu unserer Homepage

B) Problemfelder
- Darstellung und Umschalten der Seiten, wenn sehr viele Vertretungen vorhanden sind
- knappe Zeit für die Entwickler, da es nur noch 7 Wochen bis zur Abgabe sind

C) Weitere Aufgaben und Ziele
- Fertigstellung einer Client/Sender-Steuerung inkl. Konfigurationsseite, um die Monitore zentral zu steuern
- Anpassung Genehmigungsworkflow für die News
- Entwicklung eines rechtebasierten Genehmigungsworkflow für die Ankündigungen
- Entwicklung eines eigenen Browsers zur Darstellung des eBB auf den Monitoren
- Implementierung des Front-End-Design (nach Design-Entwurf)

- Erstellung einer Leonardo-Präsentation
- Erstellung einer Benutzerhilfe
- Eventuelle Erstellung eines kurzen Trailers
27.01.2013 - 08:51 Uhr
Marc Hoitz
Statusbericht 008 (Team Redaktion): Fertigstellung eBlackboard-Pflichtenheft
Wir sind jetzt soweit mit dem Pflichtenheft fertig. Nach einigen Treffen konnten wir uns auf den Inhalt des Pflichtenheftes einigen.

A) Bisherige Ergebnisse:
- Fertigstellung des Pflichtenheftes

B) Problemfelder:
- die knapp bemessene Zeit nach Schulschluss, in der wir alle zusammen das Pflichtenheft ausarbeiten konnten.

C) Weitere Aufgaben und Ziele:
- Durchführung der im Pflichtenheft angeführten Punkte.
14.01.2013 - 19:34 Uhr
Felix Müller
Statusbericht 007 (Team Grafik): Aufteilung der Vertretungsplandaten
Als Grafiker hatten wir uns die Herausforderung gestellt, das eBlackboard gut strukturiert und informativ darzustellen. Die Gestaltung des Vertretungsplan verlief anfangs holprig, doch wir ließen uns nicht entmutigen das perfekte Design zu erreichen. Durch die vielen Vertretungen der einzelnen Zweige der FLS waren wir gezwungen ein dynamisches Design zu entwickeln, welches eine eventuelle Ausblendung bestimmter Elemente mit integriert.

A) Bisherige Ergebnisse
- Aufteilung der Zweige in zwei Spalten BG, HBFS, BFS // BS
- Ausblendung der Elemente Nachrichten und Ankündigungen
- Möglichkeit der Umschaltung für bestimmte Szenerien wie Feueralarm oder Elternabende

B) Problemfelder
- Icons fehlen für die jeweiligen Arten wie z.B. Freistunde, Vertretungsstunde (Lehrer und Fach) und Termine

C) Weitere Aufgaben und Ziele
- Überarbeitung des Designs
08.01.2013 - 16:02 Uhr
Simon Seyer
Statusbericht 006 (Team Entwicklung): Backend-Programmierung
Um die Vorgehensweise nachvollziehen zu können, werde ich zuerst einmal den Weg der Vertretungsplan-Daten beschreiben: Nachdem unser stellvertretender Schulleiter eine HTML-Datei aus dem Stundenplanprogramm exportiert hat, wird diese mit einem selbst geschriebenen Programm automatisiert auf unseren Server hochgeladen, wo sie analysiert und in ihre Einzelteile zerlegt wird. Im Anschluss wird für jede Vertretung ein Datensatz in der Datenbank angelegt, in dem alle Informationen wie Datum, Stunde, Vertretungslehrer und, ganz wichtig, der Stand der Daten gespeichert wird. Bei einem Abruf, das heißt jemand fordert die Daten an, indem er die Vertretungsplan-Seite lädt, werden nun alle Daten mit dem aktuellsten Stand aus der Datenbank geladen und jeweils in ein PHP-Objekt gespeichert. Diese Menge von PHP-Objekten muss im Anschluss wieder strukturiert werden. Bei dem Standard-Vertretungsplan unter www.fls-wiesbaden.de/vplan zum Beispiel nach "Tag -> Klasse -> Vertretung". Diese strukturierten Daten werden nun an das Frontend gesendet, welches die Daten dann optisch ansprechend darstellt. Das Frontend wird noch Thema eines weiteren Berichtes.

A) Bisherige Ergebnisse
- Das Backend wurde so umgestellt, dass es die gewünschte Struktur für den Vertretungsplan erstellen kann. Diese ist "Tag -> Schultyp -> Vertretung", wobei sich Schultyp auf die verschiedenen Bereiche unserer Schule bezieht. Konkret gehören hier Berufliches Gymnasium, Berufsfachschule und höhere Berufsfachschule zu der ersten Gruppe und die Berufsschule zu der zweiten. Die Schultypen sind also nach Voll- und Teilzeit-Schultyp getrennt. Diese Aufteilung ist erstmal vorläufig, da erst mit richtigen Daten getestet werden kann, wie der Anteil der Vertretungen ist und demnach dann noch eine Optimierung vorgenommen werden kann.

- Vertretungen, die über mehrere Stunden gehen (also zum Beispiel Doppelstunden), werden zusammengefasst, um sie möglichst platzsparend darstellen zu können

B) Problemfelder
- Die Erstellung der Struktur war noch ziemlich statisch. Das heißt, dieser Code-Abschnitt war nicht einfach auf die neuen Anforderungen anzupassen. Dies ist der Tatsache geschuldet, dass man bei der ersten Programmierung nicht von einer Erweiterung der Ansichten ausgegangen ist. Aus diesem Grund musste dieser Abschnitt komplett neu überarbeitet werden und ist nun für alle Arten von Strukturen leicht erweiterbar.

- Die Funktion für Zusammenfassen der Vertretungen über mehrere Stunden machte ein paar Probleme, da dort ein Vergleich aller Attribute erfolgt, bei dem das Attribut "Stunde" ausgespart wird, um diese Vertretungen zu finden. Dieser Vergleich sollte funktionieren, egal wie viele Attribute die Vertretung hat und so wird nun von dem ersten zu vergleichenden PHP-Objekt eine Liste der Attribute erstellt und jeder Eintrag dieser Liste mit dem entsprechenden Attribute des zweiten Objektes verglichen. Dafür haben wir eine komplexe Funktionalität von der Programmiersprache PHP namens Reflection eingesetzt, die leider von den PHP-Entwicklern schlecht dokumentiert wurde.

C) Weitere Aufgaben und Ziele
- Im nächsten Schritt geht es darum, das erste Frontend auf der Grundlage des erstellten Designs zu erzeugen und die Anbindung an das Backend zu schaffen, welches in diesem Bericht beschrieben wurde.
05.01.2013 - 10:14 Uhr
Michael Schlosser
Statusbericht 005 (Team Beschaffung und Verkabelung): Stand Verkabelung und Angebote für die LCD-Monitore
Im ersten Schritt ist vorgesehen, erst einmal zwei Bildschirme zu beschaffen: Ein größerer LCD-Monitor (47' Zoll) für den Eingangsbereich unseres Hauptgebäudes und ein kleinerer (42' Zoll) für die Pausenhalle im Atrium. Da die vorgesehenen Standorte der eBlackboards noch keinen Strom- und Netzwerkanschluss besitzen, müssen die entsprechenden Leitungen noch verlegt werden.

A) Bisherige Ergebnisse
- Die Gespräche mit der Schulleitung haben stattgefunden und uns wurden die Strom- und Netzwerkanschlüsse im Atrium und Hauptgebäude bis Ende März zugesagt.

- Die Anschaffung der beiden LCD-Monitore soll Anfang Februar erfolgen.

- Die Angebote für zwei TFT-Syncmaster-Monitore von Samsung- bzw. TFT-LCD-Flatron-Monitore von LG inkl. Halterungen wurden bereits eingeholt


B) Problemfelder
- Es muss geklärt werden, ob die in den Monitoren integrierten PCs bzw. Mediaplayer ein Webkit-Paket besitzen bzw. HTML 5.0 interpretieren. Ansonsten müssen noch geeignete PC-Einschub-Module für die eBlackboards beschafft werden.


C) Weitere Aufgaben und Ziele
- Entscheidung für ein Angebot und Bestellung eines LCD-Monitors zu Testzwecken. Vorher sollte das Frontend für die eBlackboards mit den wichtigsten Funktionalitäten implementiert sein.
02.01.2013 - 18:25 Uhr
Marc Hoitz
Statusbericht 004 (Team Redaktion): Erstellung eBlackboard-Pflichtenheft
In den letzten Tagen haben wir uns auf die Kriterien des Pflichtenhefts geeinigt.

A) Bisherige Ergebnisse:

Kriterien des Pflichtenhefts:
1. Zielbestimmung (Musskriterien und Wunschkriterien)
2. Produkt-Einsatz (Anwendungsbereich und Zielgruppe)
3. Benutzeroberfläche (mit kurzer Beschreibung und Screenshot)
4. Funktionalitäten
5.Informationsfluss
6. Qualitätsziele
(mit konkreten Aussagen über messbare Qualitätskriterien wie z.B. Funktionalität, Zuverlässigkeit, Effizienz, Benutzerfreundlichkeit, Portabilität, Wartbarkeit, Lebensdauer
7. Entwicklungsumgebung (Software- und Hardware-Umgebung)

B) Problemfelder:
- keine.

C) Weitere Aufgaben und Ziele:
- Gemeinsames Erstellen des Pflichtenhefts in den nächsten drei Wochen
31.12.2012 - 16:48 Uhr
János Adelsberger
Statusbericht 003 (Team Grafik): Logo und Layout Entwicklung
Besonders zu Beginn des Leonardoprojektes war es für uns wichtig, so schnell wie möglich ein Logo zu entwickeln um uns von den anderen Projektseiten abzuheben. Ein zu beachtendes Kriterium war, dass das Produkt klar erkennbar sein soll und somit wenig Erklärung bedarf. Zudem musste ein Slogan entworfen werden, der das Ziel, das digitale Zeitalter nun endlich auch an Schulen zu bringen, auf den Punkt bringt.

A) Bisherige Ergebnisse:
- Konzeption des Farbschemas entsprechend der Corporate Identity (CI) der Schule und erster Entwurf des Layout und Design.

- Aussagekräftiges Logo inklusive Slogan.

B) Problemfelder:
- Layout des eBlackBoards bei Stoßzeiten wie z.B. den mündlichen Abitur Prüfungen. Eventuelle Ausblendung irrelevanter Informationen und Elemente.

C) Weitere Aufgaben und Ziele:
- Weitere Ideen zum Layout, insbesondere zur Unterbringung von mehr Vertretungen.

- Entwicklung von Icons für entsprechende Änderungen im Stundenplan.
29.12.2012 - 00:07 Uhr
Lukas Schreiner
Statusbericht 002 (Team Administration): Einrichtung eBB-Bereich in Trac
Spätestens ab dem Kick-Off-Meeting war es abzusehen: es werden noch viele Aufgaben auf uns zukommen und die verschiedenen Teams müssen organisiert werden. Hier greifen wir nun auf unsere Projektmanagement-Plattform "Trac" zurück.

A) Bisherige Ergebnisse
- Einrichtung der verschiedenen Projekt-Teams in Trac.

- Einrichtung einer Trac-Seite, die alle Tickets gruppiert nach Projekt-Team übersichtlich darstellt (siehe Foto von Trac). Dadurch ist sehr schnell erkennbar wer in welchem Team für welche Tickets zuständig ist und wie der aktuelle Status ist.

- Für das einfache Vorschreiben von Statusberichten für den Blog wurde eine Wiki-Vorlage in Trac erstellt (zweites Foto mit Vorlagen-Auswahl).

B) Problemfelder
- Eine saubere Gruppierung für das eBB-Projekt ist aktuell nur über die speziell eingerichtete Trac-Seite möglich, da andernfalls eine Neustrukturierung der bestehenden Tickets und Komponenten notwendig gewesen wäre.

C) Weitere Aufgaben und Ziele
- Auf die korrekte Zuweisung der Tickets zu den Komponenten und Meilensteinen achten
28.12.2012 - 18:51 Uhr
Michael Schlosser
Statusbericht 001 (Team Projektmanagement): Kick-Off-Veranstaltung und Projektbeginn
Nachdem wir am 21.12.2012 unsere Kick-off-Veranstaltung hatten, kann unser Projekt nun endlich beginnen.

A) Bisherige Ergebnisse:
- Einigung auf einen groben Entwurf bezüglich dem Aufbau und den Grundfunktionalitäten (Siehe Foto)

- Erstellung einer Roadmap (Wer macht was?) und Verteilung der Aufgaben auf die einzelnen Projektteams Projektmanagement, Entwicklung, Redaktion, Grafik, Beschaffung und Verkabelung, Testing sowie Administration

B) Problemfelder:
- noch keine. Prinzipiell sollte alles machbar sein. Allerdings ist die Zeit bis zum 24. März knapp bemessen.

C) Weitere Aufgaben und Ziele:
- Projektteam Administration: Einrichtung eines DSB-Projektbereichs auf unserer Projektmanagementplattform trac und Anlage der ersten Tickets für die Umsetzung
(Hinweis: Über unsere Projektmanagementplattform trac erfolgt traditionell der komplette Austausch. Mittels eines Ticketsystems definieren wir hier Anforderungen, verteilen die Zuständigkeiten, stellen Zwischenergebnisse ein, testen diese und geben sie frei)

- Projektteam Projektmanagement mit Unterstützung aller Projektmitglieder: Festlegung des endgültigen Terminplans

- Projektteam Redaktion mit Unterstützung aller Projektmitglieder: Erstellung eines Pflichtenheftes auf Basis der bisher definierten Grundfunktionalitäten

- Projektteam Grafik: Erstellung eines Logos für unser Projekt und erster Design-Entwurf für die Benutzeroberfläche

- Projektteam Entwicklung: Anpassung des Genehmigungsworkflows für die News und Programmierung eines Prototypen für die Benutzeroberfläche

- Projektteam Beschaffung und Verkabelung: Einholen von Angeboten für einen geeigneten Bildschirm
trennstrich
3321 Leute haben dieses Projekt angeschaut
zurück
verlinkung
trennstrich