05.Arbeitsprozess - Gandiko/WBA2SS15VollGanderManke GitHub Wiki

#Der Arbeitsprozess

Im Laufe des Projekts kam es zu einigen Schwierigkeiten, welche sich teilweise mithilfe der Tutoren und teilweise durch einfache Kommunikation lösen ließen. Hier werden jetzt nur diese Erwähnt, welche einen Signifikanten Zeitaufwand Inanspruchnahmen. Zudem wird hier die Herangehensweise des Teams erläutert.

##Kommunikation

Zu Beginn der Veranstaltung gab es einige Probleme mit der Verständigung zwischen dem Team und den Tutoren. Dies began bereits in der Aufgabenstellung, bei der die Ziele bzw. die Erwartungen nicht deutlich wurden. So wurden die ersten Projektideen abgelehnt, ohne jedoch die Probleme der Idee genauer zu erläutern. Gegen Ende der Workshop-Phase funktionierte die Kommunikation dann besser, wodurch das Team sich dann auf das Projekt und dessen Ausarbeitung konzentrieren konnten.

##Kalender

Bei einem Verleihsystem stellt sich die Frage, wie man dem User veranschaulichen kann, wann ein Gerät (z.B eine Kamera) zur Verfügung steht und wann nicht. Dafür stellte das Team die Überlegung an, einen Kalender zu erstellen indem man farbig markiert, wann ein Gerät bereits verliehen ist. Dort stieß das Team auf das Problem, dass man in Redis nur String variablen abspeichern kann, was im Konflikt mit der Ursprungsidee stand, da dafür Integer Werte benötigt werden würden.

Nach einigen Recherchen wurde dem Team bewusst, dass ein Kalender in den gewünschten Vorstellungen außerordentlich aufwendig und damit für den gegebenen Zeitraum zuviel wäre. Auch die Überlegung einen boolschen Wert in den Code einzubauen, wurde durch die Einschränkung der Datentypen in Redis wieder verworfen. Somit wurde nach einer Ausweichmöglichkeit gesucht. Die Lösung war, dem Verleiher zwei Auswahlmöglichkeiten zu geben, welche je nach Auswahl auch farbig markiert werden. Zur Auswahl stehen:

1.Verfügbar: ja (grün)
2.Verfügbar: x (rot)

Die Idee dahinter ist, dass der Dienstgeber die Möglichkeit hat, selbst zu entscheiden wann sein Equipment angeboten werden kann und wann nicht. Ob das Equipment zu dem Zeitpunkt verliehen wird und ob es verfügbar ist, wird per E-mail-Verkehr selbstständig geregelt.

##Ressourcen

Ein weiterer wichtiger Punkt bestand darin die nötigen Ressourcen festzulegen. Diese sollten, wenn möglich, als Datenobjekt redundanzfrei sein. Die Ressourcen änderten sich im Laufe des Projekts stetig, da sich auch das Projekt veränderte. So standen zu Anfang vor allem Dienstleister wie beispielsweise Kameramänner, Maskenbildner, Tontechniker uns. im Vordergrund, später dann eher Gegenstände. Bei diesem Prinzip ist das Team auch geblieben, wobei es sich auf 6 Ressourcen beschränkt hat, welche sind:

1.User
2.Kamera
3.Objektive
4.Halterungen
5.Drohnen
6.Beleuchtung

Eine genauere Beschreibung der einzelnen Ressourcen findet man im Wiki über den Reiter "Ressourcen".

##Das Design

Dem Team war es wichtig ein Webdesign zu erstellen, welches möglichst selbsterklärend und übersichtlich ist. Dafür wurden sich andere Webpages angesehen und überlegt welche Vor- und Nachteile es bei den einzelnen Seiten gab. Das Ergebnis wurde dann versucht in das Design des Verleihsystems mit einfließen zu lassen. Der Service sollte einen einzigen Einstiegspunkt haben, von wo aus man mit Hilfe von Hypermedia durch die verschiedenen Zustände navigiert werden kann.

Weiterhin verständigte sich die Gruppe darauf, dass zwar jeder auf das Profil zugreifen und auch ein Rating abgeben kann, aber ausschlaggebende Veränderungen nur von dem Nutzer selber und auch erst nach dem Einloggen. Weiterhin wurde überlegt, inwiefern das Equipment präsentiert werden soll. Die Erste Überlegung war, dass der Interessent über das Profil auf das zugehörige Equipment gelangt. Dies wurde dann jedoch wieder verworfen, da es fernab der Realität und zudem nicht logisch ist.

Wenn eine Person nur ein bestimmtes Objekt, wie z.B eine Kamera braucht, wäre es nicht sinnvoll von einem Profil zum nächsten zu gehen, in der Hoffnung das der User eine Kamera verleiht. Somit verständigte das Team sich darauf auf der Home-Seite für jedes mögliche Equipment einen Reiter zu erstellen, der nach dem Aktivieren dann eine Liste aller Gegenstände dieser Art ausgibt.

Hat man sich für ein Equipment, wie beispielsweise eine Kamera entschieden, kann der User ganz einfach daraufklicken und wird auf die Profilseite des Verleihers weitergeleitet. Dort kann sich der Interessent dann per E-mail an den Verleiher wenden, um die Einzelheiten zu klären. Die E-mail kann bereits im Browser verfasst werden, indem der User auf den dafür vorgesehenen Button auf der Profilseite klickt.
Für die Benutzerfreundlichkeit wurde darauf geachtet, dass Statuscodes mit ein implementiert wurden, sodass bei fehlerhaften Eingabe oder ähnlichen Problemen diese dem User mitgeteilt werden.

##Das Ratingsystem

Wie bereits erwähnt, wurden sich einige Webpages für Research-Zwecke angesehen. Bei diesem Prozess entstand die Idee ein Rating System anzulegen. Das soll dazu dienen um das Equipment zu bewerten. Das Team stellte die Überlegung an, dass wenn man einen Gegenstand kaufen/leihen möchte, gerne mehr über den Zustand erfahren würde und zwar am Besten von Personen, die dieses bereits genutzt haben.

Vorgesehen war es ursprünglich, dass der User alle Rezessionen angezeigt bekommt, die über ein bestimmtest Equipment verfasst wurde. Um dies zu verwirklichen, wurde zunächst eine eigene Ressource "Verleih" angelegt um darüber dann eine Schnittstelle für die Rezessionen und die User zu schaffen. Leider kam es da zu Problemen, die das Team nicht lösen konnte. Aus diesem Grund, ist dieses Feature nun leider nicht in dem aktuellen Web-Service enthalten. Bei einer Fortführung des Projektes wäre es jedoch nicht auszuschließen, dieses noch hinzuzufügen.

##Funktion "PUT"

Sowohl im Dienstnutzer, als auch im Dienstgeber wurden syntaktisch korrekte "PUT"-Funktionen, welche es ermöglichen sollten Equipments und Users nachträglich zu bearbeiten, implementiert. Jedoch wurde dem Team zeitlich zu spät bewusst, dass HTML-Formulare nur "POST" und "GET"-Funktionen unterstützt. Dies war in der HTML-Dokumentation für das Team auf den ersten Blick nicht ersichtlich. Eindeutig nachgelesen wurde dies auf "stackoverflow.com". In der Datei "updateProfile.ejs" ist die syntaktisch korrekt implementierte "PUT"-Funktionen einzusehen.

Home