Persönlich: Abschlusspräsentation

Obwohl wir zum Ende des Projekts einen umfangreichen und funktionieren Prototypen fertigstellen konnte, entschieden wir uns als Gruppe nicht am Coding Davinci Wettbewerb teilzunehmen.

Die Gründe dafür waren vielfältig, aber für die Gruppe ausschlaggebend, dass es für einzelne wichtige Terminüberschneidungen gab, unsere Anmeldung aus technischen Gründen über das Google Docs Formular nicht bei den Veranstaltern ankam und wir nicht die Ziele erreichen konnten, die wir uns gesetzt hatten.

Der letzte Punkt war besonders für mich relevant. Wie ich zuvor schon schrieb, war eines meiner Ziele mich mit modernen Webtechnologien, im Speziellen AngularJS, zu beschäftigen. Und ich wollte eine dynamische, responsive Webseite, die von allen Geräten benutzbar ist.

Leider war das im  Rahmen dieses Projektes nicht möglich. Einerseits, da uns als gemeinsame Gruppe die Expertise fehlte das im Rahmen der kurzen Zeit technisch zu realisieren. Andererseits, da sich unser Layout immer weiter in Richtung einer App entwickelte.

Ich hatte zwar Erfahrungen mit HTML, CSS, JavaScript und MFC-Frameworks, aber noch nie konkret mit AngularJS und Django gearbeitet. Und Philipp hatte, wie er transparent am Anfang mitteilte, noch gar keine Erfahrungen in der Webentwicklung. Unter diesen Voraussetzungen war es utopisch AngularJS als weiteres Framework mit steiler Lernkurve einzusetzen. Damit ließen wir auch die Idee einer dynamischen Seite hinter uns entwickelten wieder klassische Views, die jeweils eine vollständige HTML Seite ausliefern.

Wie ich im letzten Beitrag schon anmerkte änderte sich unser Design ziemlich oft. Während es sich am Anfang noch stark an den von Bootstrap vorgegeben Strukturen orientierte, hatten wir am Ende eher ein für eine App geeignete Struktur: 100% hohe Seitenleisten am linken und rechten Bildschirmrand und einzelne horizontal scrollbare Blöcke. Diese Veränderung führte nicht nur dazu, dass wir sehr viel selbst Entwerfen mussten und eigentlich kein einziges Bootstrap Feature mehr nutzen, sondern auch zu einem Layout, dass nur unter bestimmten Bedingungen gut aussieht. Es ist möglich ein solches Layout für beliebige Auflösungen anzupassen, aber nicht in diesem kurzen Zeitrahmen.

Somit konnten wir, aus meiner Sicht, zentrale Ziele unseres Projekts nicht erreichen, weshalb ich keine große Leidenschaft hatte das Projekt im Rahmen der Abschlusspräsentation zu pitchen.
Wie gesagt wäre das allein kein Grund gewesen auf die Abschlusspräsenstation zu verzichten, aber da unserer Anmeldung eh nicht geklappt hätte und ich unter Umständen alleine auf der Bühne hätte stehen müssen, entschieden wir uns als Gruppe gegen die Präsentation.

Der sehr negative Eindruck kurz vor Ende des Projekts hängt wahrscheinlich auch mit dem Arbeitsdruck in der Woche zuvor zusammen. Wir hatten lange gemeinsame Treffen und viele kleine Issues, die sich auf Details des Layouts bezogen und jedes mal mehr Zeit in Anspruch nahmen als wir planten. Insgesamt hatten wir zu diesem Zeitpunkt einfach zu oft auf unsere Musterseite geschaut und damit den Bezug auf die positiven Seiten verloren.

Jetzt mit ein paar Tagen Abstand, sehe ich viel deutlicher wieviel wir geschafft haben und bin begeistert wieviel wir in der kurzen Zeit geschafft haben. Die eigenen Ansprüche sind halt doch oft zu hoch und man verliert den Blick für das Gesamte wenn man sich nur auf die Details und offenen Aufgaben konzentriert.

Persönlich: Kommunikationsprobleme

Mein konkreter Wechsel in die Muster/Pattreator Gruppe gestaltete sich leider ziemlich holprig, da erstmal Philipp und dann ich eine Woche krankheitsbedingt ausfielen. Als komplette Gruppe konnten wir uns daher erst in meiner 3. Woche treffen und beginnen unser gemeinsames Vorgehen zu koordinieren.

Zu diesem Zeitpunkt wurde auch schon klar, dass auf Entwicklerseite E-Mails zur Koordination nicht ausreichen und wir entschieden uns für die Aufgabenverteilung den Issuetracker auf Github zu verwenden.  Allerdings zeigten sich auch hier Startschwierigkeiten.

Wie im letzten Beitrag erwähnt hatte mein Informatikkommilitone bislang keine Erfahrung in der Webprogrammierung und so fiel mir die Rolle zu Aufgaben festzulegen und zu verteilen.  Wie schnell klar wurde bedarf das jedoch auch einiger Erfahrung. Meine ersten Aufgabenpakete waren viel zu groß und ungenau beschrieben und führten damit nicht zu Fortschritt, sondern zu Frust.  Zudem hatte ich komplett unterschätzt wie viel Arbeit es bedeutet sich komplett neu in HTML, CSS und JavaScript einzuarbeiten.

Zudem änderte sich von Woche zu Woche das von unserem Designer entworfene Layout, was zu viel Stress und gefühlt unsinniger Arbeit führte. Der Fluch iterativer Entwicklung: Wenn sich ein Feature das Stunden an Zeit gefressen hat im nächsten Test als unpraktisch herausstellt fliegt es wieder raus. Das ist natürlich sehr sinnvoll, aber auch deprimierend. Leider entfernten sich die Entwürfe  immer weiter von unserem ursprünglichen Konzept und damit auch des schnellen Prototypings mittels Bootstrap.

Außerdem zeigten sich Kommunikationsprobleme in der Zusammenarbeit, da wir (eigentlich bis zum Ende) nur PDF Entwürfe bekamen, aus welchen wir dann umständlich Farbcodes rekonstruieren, Abstände und Größen raten sowie einzelne Elemente ausschneiden mussten. Auch auf mehrfache Nachfrage bekamen wir keine Farbpalette oder die Abmessungen in Pixeln.

Insgesamt waren die ersten Wochen sehr frustrierend für uns alle. Und ich war kurz davor das Projekt zu schmeißen und mir ein Softwareprojekt für die Vorlesungsfreie Zeit zu suchen.

Glücklicherweise hatten wir vorher doch nochmal ein längeres Treffen, bei dem wir die Probleme ansprechen und Lösungen suchen konnten. Die wichtigste Änderungen in unserer Gruppenstruktur waren dann regelmäßige gemeinsame Treffen um unserer Kommunikation zu verbessern. Die Treffen ermöglichten es uns sowohl technische Probleme oder verschiedene Konzeptvorstellungen gemeinsam zu diskutieren und zu lösen, als auch eine genauere Aufgabenspezifikation.

Dabei zeigte sich auch, dass Gamification beim Programmieren super funktioniert, da kleinere Aufgaben/Issues viel leichter bearbeitet und eben auch geschlossen werden konnten. Und jedes geschlossene Issue, den aktuellen Milestone Fortschrittsbalken weiter Grün färbte und ein Geühl von Erfolg vermittelte.

Trotz des ganzen Stresses, fand ich den Wechsel in die neue Gruppe gut, da es wichtig ist solche Kommunikationsprobleme, aber auch Lösungswege, kennen zu lernen.

Persönlich: Gruppenwechsel

Nach dem ersten „Speeddating“ und der Datenvorstellung hatte ich mich, um in den Metaphern des Kurses zu bleiben, mit der der Gruppe Stadtgeschichten „verlobt“. Das war meinem Interesse an Stadtpolitik, als auch den Gruppenmitgliedern geschuldet,  die ich seit meinem ersten Informatik Semester kenne.

Die Gruppe hatte sich relativ schnell entschieden ein Objekt zu entwerfen, welches von Person zu Person weitergereicht werden und Geschichten sammeln sollte. Ein spannendes Projekt, das aber erstmal die Entwicklung einer Android App bedeuten würde. Eigentlich sehr interessant, aber ich hatte das Softwareprojekt neben vielen anderen Gründen gewählt, da ich mich mit neueren Webtechnologien wie AngularJS auseinandersetzen wollte.

Das allein wäre aber kein Grund gewesen die Gruppe zu verlassen, da ich ihre Dynamik sehr positiv empfand. Das lag wahrscheinlich auch an der freundschaftlichen Zusammensetzung.

Allerdings hatte ich bedenken mit Freunden zusammenzuarbeiten, da ich zwar weiß wie gut man in solchen Konstellationen Brainstormen kann, aber auch die Konflikte kenne, wenn Aufgabenverteilungen nicht funktionieren und sich Kritik an der Arbeit mit freundschaftlicher Sympathie vermischt.

Ausschlaggebend für meinen Wechsel, war jedoch der Hilferuf der Mustergruppe, die auf einmal nur noch zu zweit waren und ohne weitere Unterstützung das Projekt hätten abbrechen müssen.

Das Musterkonzept entsprach ziemlich genau meinen Erwartungen an das Softwareprojekt. Das Ziel war es eine moderne Webapplikation zu entwickeln, die der besseren Darstellung und Weiterverwendung der von der HTW zur Verfügung gestellten Stoffmuster dienen sollte. Also perfekt dafür geeignet endlich mal ein konkretes Projekt mit Django, AngularJS und co. umzusetzen.

Dazu kam noch ein ansprechendes Layout des Designers und die Herausforderung der Zusammenarbeit mit einem unbekannten Team.

Trotz des schon fortgeschrittenen Projektverlaufs und des schon weitgehend feststehenden Konzeptes entschied ich mich daher nach einem sehr kurzen Kennenlernen und in Absprache mit meiner alten Gruppe zu einem Wechsel.

Neben Expertise und Motivation brachte ich auch einen Schwung technischer Ideen mit: Wie oben schon erwähnt sollten Django und AngularJS die Grundlage der Applikation bilden und mit Bootstrap schnell ein Designprototyp erstellt werden.
Das weder der Designer noch der zweite Entwickler bislang Erfahrungen mit Webentwicklung hatten, übersah ich in den ersten Planungen jedoch leider.

Pattreator Abschlusspräsentation

Für unsere Abschlusspräsentation haben wir zwei verschieden Foliensätze, da wir einerseits nochmal aus Designsicht auf das Konzept eingehen und andererseits Details zur technischen Umsetzung vermitteln wollten.

P.S. Leider erlaubt die Uploadfunktion keine Uploads über 10MB und PDFs unter Linux zu komprimieren scheint ein Ding der Unmöglichkeit. Deswegen hier nur Links zu einem externen Hoster.

Technische Reflektion

Die von uns verwendeten Technologien werden hier noch einmal kurz kritisch auf ihre Zukunftssicherheit betrachtet.

Ionic Framework für das Frontend

Das Ionic Framework stellt viele nützliche Dinge bereit. Unter anderem sind oft benötigte Elemente, wie z.B. Listen, Modals, Buttons usw. leicht einsetzbar und funktionieren auf anhieb.

Es werden außerdem eine beträchtliche Anzahl an hochwertigen Icons direkt mitgeliefert und durch das Aufbauen auf AngularJS kann eine Vielzahl an externen Libraries ohne große Umstände eingesetzt werden.

Der Schwerpunkt für das Einsatzgebiet liegt jedoch in der Entwicklung von simplen Single-Page Apps. Eine Anwendung wie floradex lässt sich zwar auch damit entwickeln, es müssen aber an vielen Stellen Umwege und Hindernisse in kauf genommen werden. Hier stellt sich die Frage, ob es nicht sinnvoller ist auf Ionic zu verzichten und nur AngularJS zu verwenden. Besonders bei Verwendung der bereitgestellten Komponenten nicht 100% in dem vorgesehen Kontext kam es zu unüberbrückbaren Problemen. (Wie z.B. das Springen des Popovers bei Auswahl eines Merkmals im Menü) H

Zum Zeitpunkt der Auswahl waren unsere Kenntnisse in Angular nicht ausreichend um in der kurzen Zeit eine fertige Anwendung zu schreiben. Jetzt hingegen wäre es effektiver diese direkt darin zu schreiben.

JSON als Dateiformt

Die Daten werden als einfache JSON Dateien gespeichert und komplett eingelesen. Dies funktioniert bei 35 Pflanzen sehr gut ist aber natürlich keine Lösung für größere Mengen. Hier wäre eine richtige Datenbank angemessen.

WebApp

Das Dynamic Binding (Listener auf Variablen und Funktionen ändern die Seite bei Veränderung dieser) in AngularJS ist zwar extrem hilfreich, sorgt aber dafür, dass größere Anwendungen wie Floradex immer langsamer werden, umso mehr Funktionalität hinzukommt.

Entweder muss dieser Prozess besser gehandhabt werden (Also die Listener Events von Hand senden, falls dies möglich ist?) oder die Anwendung sollte direkt als Native Anwendung geschrieben werden.

Zwar habe ich eingesehen, dass WebApps ein plausibler Weg sind um Anwendungen zu schreiben, aber sie haben einen Anwendungfall, der eingehalten werden muss. Kleine Anwendungen mit klaren Wegen und gut getrennter Funktionalität lassen sich so leicht auf mehrere Platformen übertragen.  Eine Anwendung wie Floradex, bei der immer sehr viel gleichzeitig auf einer Seite passiert leidet sehr unter den Limitierungen von HTML und JS.

Fazit

Dies mag alles sehr kritisch klingen, aber ich bin mit dem Ergebnis in dieser kurzen Zeit sehr zufrieden. Der Weg den wir eigeschlagen haben mag zwar nicht perfekt gewesen sein, aber ich habe sehr viel hinzugelernt.