WiFi Scout: Laborbericht № 1

Achtung: Dieser Beitrag ist schon etwas älter.
Es kann sein, dass sein Inhalt nicht mehr aktuell ist, Links veraltet sind oder dass auch niemand mehr auf neue Kommentare antwortet.

Die ersten zwei Iterationen bei der Entwicklung von WiFi Scout sind angeschlossen. Zeit also, für einen kleinen Zwischenbericht, Rückblick und Ausblick. In den zwei Iterationen wurde eine grundlegendes System entwickelt, welches jetzt um weitere Funktionen ergänzt und Details entwickelt werden. So dass nach dem aktuellen Stand, eine erste Version nach Abschluss der Iteration #3 auf die Tester losgelassen werden kann. Das ist leider wesentlich später als ich eigentlich geplant hatte, da ein wichtiger Standpunkt in der Entwicklung das möglichst frühzeitige Nutzerfeedback ist. Nicht nur der Entwicklungsstand von WiFi Scout, sondern vor allem unausweichliche Vorarbeiten am Server, verhindern eine frühzeitige Veröffentlichung außerhalb der Entwicklungsumgebung.

Rückblick

Wie ich in einem früheren Beitrag schon geschrieben habe, wurde das gesamte Projekt in einzelne, kleinere Teile zerlegt: den so genannten Iterationen. In der ersten Iteration (#0) war es das Ziel, ein erstes Interfacedesign und einen HTML-Mockup zu entwickeln. Zudem war die Einrichtung der Entwicklungsumgebung, sowie die Entwicklung der Funktionalität zum Anzeigen und Eintragen von Hotspots geplant. Dies habe ich in den eingeplanten 14 Tagen jedoch nicht mehr umsetzen können und diese Punkte relativ schnell aus der Planung wieder gestrichen. Am Ende der Iteration #0 gab es einen HTML-Dummy, der für die wichtigsten Seiten entwickelt wurde und die Basis für das weitere Projekt darstellte.

Bei der Planung für die zweite Iteration wurden die zuvor gestrichenen Punkte wieder auf die Liste gesetzt, ergänzt um den Punkt der Prüfung auf Duplikate, beim Eintragen von Hotspots. Dieses mal habe ich die Länge der Iteration auf vier Wochen festgelegt. Der Grund für diesen langen Zeitraum (normalerweise sind die Zyklen kürzer) ist, dass ich täglich nur einige Stunden an WiFi Scout arbeiten kann. Dank dem eingesetzten Framework Ruby on Rails konnte ich recht schnell vorzeigbare Ergebnisse erzielen. Leider hatte sich jedoch die Duplikatsprüfung etwas in die Länge gezogen. So konnte ich die Seiten zum Anzeigen der Hotspots nicht vollständig fertigstellen.

Der Designprozess

Entwickelt wurden in der ersten Phase das Design der Start- und Detailseite für einen Hotspot. Die ersten groben Entwürfe entstanden im Notizbuch. Dabei habe ich mich von den kleinen Teilen (die darzustellenden Informationen) zu den großen Teilen und schließlich zu dem Aussehen der gesamten Seite vorgearbeitet. Diese Vorgehensweise im Webdesign wird als »Epicenter Design« bezeichnet. Dazu werde ich demnächst noch einen gesonderten Beitrag schreiben.

Nach dieser Notizbuch-Phase habe ich die Startseite auf der gestalterischen Ebene in Photoshop ausgearbeitet. Aufgrund der Skizzen hätte die Entwicklung in Photoshop auch übersprungen werden können. Da jedoch auch relativ viele Grafiken entworfen werden mussten, konnte ich diese direkt in ihrem gesamten Kontext betrachten und somit besser gestalterische Entscheidungen treffen. Aufgrund des Zeitfaktors, habe ich bei dem Entwurf in Photoshop nur die Startseite berücksichtigt.

Nachdem Entwurf in Photoshop habe ich direkt mit der Umsetzung der Website in HTML/CSS-Code begonnen. Dabei ist mit das Framework Blueprint sehr hilfreich gewesen. Damit ist es möglich, sehr schnell einen interaktiven Dummy zu realisieren und auch Änderungen in der Aufteilung oder Anordnung durchzuführen. Zudem bringt das Framework direkt einige praktische Dinge wie Icons und fertig definierte Formatvorlagen mit. In Kombination mit jQuery und dem Plugin Polypage lassen sich auch auf einer Seite unkompliziert verschiedene Zustände einer Seite darstellen (z.B. die Ansicht für einen angemeldeten Benutzer).

User Stories

Eine weitere Methode die bei der Planung und Entwicklung von WiFi Scout zum Einsatz kam, ist das schreiben von User Stories (Anwendergeschichten). Sie helfen Anwendungen und Interfaces zu entwickeln, die stark auf den Nutzer ausgerichtet sind. Eine User Story beschreibt jeweils eine Funktionalität der Anwendung, die für den Nutzer hilfreich ist. Dadurch bleibt der Nutzer immer im Fokus und unnötiger Ballast, welcher dem Anwender keinen nutzen bringt wird so vermieden.

Mir hat das schreiben der Geschichten sehr geholfen, um die genaue Funktionsweise einzelner Aspekte der Anwendung auszuarbeiten. Das Arbeiten mit User Stories werde ich bestimmt in einer extra Beitrag beschreiben.

Abonniere den RSS-Feed für weitere Webdesign Tutorials und Artikel.

Bisher 3 Kommentare

Peter Geil 07 Mai 09

Ich habe mit der User-Story-Methode auch sehr gute Erfahrungen gemacht. Mir eine “Übersicht” aller zu modellierenden Anwendungsszenarien zu verschaffen fällt mir damit viel leichter und es ist auch einprägsamer. Habe eine ältere Auflage von Oestereichs “Objektorientierte Softwareentwicklung” (Cornelsen Verlag?) angelesen, wo die User-Story-Methodik nur als Teilinstrument bei der Planung erwähnt wird. Die anderen Planungsmethoden, die er erwähnt zielen ganz klar auf größere Projekte ab. Insofern denke ich, dass die User-Story-Methode bei kleinen und mittleren Projekten oft schon genügt.

Naja, dann hoffe ich mal für Dich, dass WiFi Scout auf rege Akzeptanz stoßen wird und die Abschlussprüfung (ihr habt auch am 14. mai, oder?) erfolgreich ausfällt.

Christian Beier 07 Mai 09

Danke, für deine aufmunternden Worte zur Abschlussprüfung (ja, ich schreibe auch am 14. Mai). Aber noch sehr ich das mit der AP nicht so eng. Das wird erst ein paar Tage vorher kommen.

Peter Geil 08 Mai 09

So wirds bei mir wohl auch sein. Kurz vorm Showdown geht dann so richtig die Muffe…

Schreibe einen Kommentar